emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Switching from old git tree


From: Kenneth Raeburn
Subject: Re: Switching from old git tree
Date: Sat, 15 Nov 2014 03:43:05 -0500

On Nov 14, 2014, at 08:53, David Kastrup <address@hidden> wrote:

> Sven Axelsson <address@hidden> writes:
> 
>> On 14 November 2014 13:20, David Kastrup <address@hidden> wrote:
>>> address@hidden (Peder O. Klingenberg) writes:
>>> 
>>>> I have been using the old git-mirror for a while.  In there, I have a
>>>> branch with some local modifications.
>>>> 
>>>> I understand that I need to check out a fresh tree now after the
>>>> conversion?  What is the smoothest way of integrating my local branch in
>>>> this new tree?  I'm a very basic git user, and the only way I can think
>>>> of is to extract the patches from my old branch and applying them by
>>>> hand in the new tree.
>>> 
>>> Using git format-patch and git am, rather than git diff and git apply.
>>> 
>>>> Is there something else I should be doing instead?
>>> 
>>> I don't think there is much of an option to do something else.
>> 
>> I suppose you could add your old repo as a local remote to the new one, and
>> cherry-pick your commits, i.e.:
>> 
>> git remote add old /local/path/to/old
>> # Fetch the data to your new repo
>> git fetch old
>> # Find the commits to pick somehow
>> git log old/master
>> # Copy to new repo
>> git cherry-pick <sha-of-commit>
> 
> Well, I was trying to avoid the "double your repository size or no money
> back" effect.  While the file and tree blobs in two differently
> converted Emacs repositories are presumably pretty much the same, the
> entire commit history is disjoint.

I just used this approach for a few of my smaller trees: After creating your 
"main" clone of the new upstream repository, clone *that* one locally (use the 
"-s" option to save disk space), then use "git remote add" and cherry-pick as 
above (or rebase if you prefer), and when finished, push the updated branch(es) 
back into your main repository, and delete the temporary repository used for 
the merging process.

More complicated local trees (I've got development branches that forked, and 
multiple merges from upstream or between branches) are harder; rebase *might* 
be up to the job, but I suspect I'm going to be experimenting with "git 
filter-branch" a bit...

Ken




reply via email to

[Prev in Thread] Current Thread [Next in Thread]