Re: Switching from old git tree

[Kenneth Raeburn <raeburn@raeburn.org>]

On Nov 14, 2014, at 08:53, David Kastrup <dak@gnu.org> wrote:

> Sven Axelsson <sven.axelsson@gmail.com> writes:
> 
>> On 14 November 2014 13:20, David Kastrup <dak@gnu.org> wrote:
>>> peder@news.klingenberg.no (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