Switching from old git tree

Switching from old git tree

[Peder O. Klingenberg]

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.  Is there something else I should be doing
instead?

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Re: Switching from old git tree

[David Kastrup]

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.

-- 
David Kastrup

Re: Switching from old git tree

[Sven Axelsson]

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>

-- 
Sven Axelsson
++++++++++[>++++++++++>+++++++++++>++++++++++>++++++
>++++<<<<<-]>++++.+.++++.>+++++.>+.<<-.>>+.>++++.<<.
+++.>-.<<++.>>----.<++.>>>++++++.<<<<.>>++++.<----.

Re: Switching from old git tree

[Sven Axelsson]

On 14 November 2014 13:35, Sven Axelsson <sven.axelsson@gmail.com> wrote:
> # Find the commits to pick somehow
> git log old/master

... or whichever branch you were using in the old repo.

-- 
Sven Axelsson
++++++++++[>++++++++++>+++++++++++>++++++++++>++++++
>++++<<<<<-]>++++.+.++++.>+++++.>+.<<-.>>+.>++++.<<.
+++.>-.<<++.>>----.<++.>>>++++++.<<<<.>>++++.<----.

Re: Switching from old git tree

[Peder O. Klingenberg]

On Fri, Nov 14 2014 at 13:35, Sven Axelsson wrote:

> On 14 November 2014 13:20, David Kastrup <dak@gnu.org> wrote:
>
>> Using git format-patch and git am, rather than git diff and git apply.
>
> I suppose you could add your old repo as a local remote to the new one, and
> cherry-pick your commits, i.e.:

Thanks, both of you.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Re: Switching from old git tree

[Nicolas Richard]

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.  Is there something else I should be doing
> instead?

Hello,

First of all, you can add the new repository as a remote of your old one
(or your old repo in your new tree, if you prefer). This means that both
old and new (rewritten) commits will live in one repository, which also
means you can use full git power instead of having to transfer patches
from one tree to the other. (although that certainly is a solution also)

Then rebasing is your friend, with its "--onto" argument.
Here's my approach. (See also "caveats" at the end)

First, find where your branch diverged from the (now deceased) official
git mirror :

MERGEBASE=$(git merge-base old-mirror-on-savannah/emacs-24 emacs-24)

In the above,
- The name of the branch old-mirror-on-savannah/emacs-24 is clear.
- "emacs-24" is my personnal branch, where I have commits
that are not in the official tree. Alternatively, you can look at the
"git log emacs-24" and write down the first SHA1 that's not a commit of
yours.

Now, you have to find a commit in the branch
emacs-new-savannah-repo/emacs-24 which looks similar to $MERGEBASE,
because that's where you want to graft your commits.

To do that, I look for an identical commit date. This is the kind of
game I can't play well, so please forgive unnecessary complicatedness :

Here's the unix timestamp of $MERGEBASE :
DATESTAMP=$(git --no-pager show  -s --format="%at" $MERGEBASE)

and here is a commit which has the same timestamp :
ONTOHASH=$(git log --format="%H %at" emacs-new-savannah-repo/emacs-24 | grep $DATESTAMP'$' | head -1 | cut -d" " -f 1)

(it's awful, surely there's a better way.)

Now you can check that $ONTOHASH and $MERGEBASE are indeed "the same"
commit, and use
git rebase --onto $ONTOHASH $MERGEBASE

Then, repeat for every branch you want to rebase.

"worked for me"... at least I think so :)

-- 
Nicolas Richard

Re: Switching from old git tree

[David Kastrup]

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.  Once it takes root in your
repository, it will take a long long time before it gets washed out
again _after_ removing all branches/references to it.  Going through
patches minimizes the data the new repository gets to see from the old
one.

-- 
David Kastrup

Re: Switching from old git tree

[Sven Axelsson]

On 14 November 2014 14:53, David Kastrup <dak@gnu.org> wrote:
> Sven Axelsson <sven.axelsson@gmail.com> writes:
>> 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.  Once it takes root in your
> repository, it will take a long long time before it gets washed out
> again _after_ removing all branches/references to it.  Going through
> patches minimizes the data the new repository gets to see from the old
> one.

Sure, but does the repo size really matter? We are not talking about data
that is transmitted upstream.

Also, isn't it sufficient to do

git remote rm old
git gc

to clean out the repo? I haven't looked into it so I'm curious.

-- 
Sven Axelsson
++++++++++[>++++++++++>+++++++++++>++++++++++>++++++
>++++<<<<<-]>++++.+.++++.>+++++.>+.<<-.>>+.>++++.<<.
+++.>-.<<++.>>----.<++.>>>++++++.<<<<.>>++++.<----.

Re: Switching from old git tree

[David Kastrup]

Sven Axelsson <sven.axelsson@gmail.com> writes:

> On 14 November 2014 14:53, David Kastrup <dak@gnu.org> wrote:
>> Sven Axelsson <sven.axelsson@gmail.com> writes:
>>> 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.  Once it takes root in your
>> repository, it will take a long long time before it gets washed out
>> again _after_ removing all branches/references to it.  Going through
>> patches minimizes the data the new repository gets to see from the old
>> one.
>
> Sure, but does the repo size really matter? We are not talking about data
> that is transmitted upstream.
>
> Also, isn't it sufficient to do
>
> git remote rm old
> git gc
>
> to clean out the repo?

If you did not forget any reference (like old bisect labels) this recipe
should work fine once you add an additional second step.  That
additional second step is "wait for more than three months" with the
default settings.

Git is really good at not terminally losing information even when you
mess up completely.  Passing a branch through a repository basically
imprints a backup on the repository that will take quite some time to
get removed again.  Often that is what you want.  When you know in
advance that you don't, it may make sense to make sure only the data you
want gets in.

-- 
David Kastrup

Re: Switching from old git tree

[Andreas Schwab]

Sven Axelsson <sven.axelsson@gmail.com> writes:

> Also, isn't it sufficient to do
>
> git remote rm old
> git gc
>
> to clean out the repo? I haven't looked into it so I'm curious.

The reflog may hold it a bit longer.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Switching from old git tree

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On 11/14/14 7:52 AM, Andreas Schwab wrote:
> Sven Axelsson <sven.axelsson@gmail.com> writes:
> 
>> Also, isn't it sufficient to do
>>
>> git remote rm old
>> git gc
>>
>> to clean out the repo? I haven't looked into it so I'm curious.
> 
> The reflog may hold it a bit longer.

And even then, you'd need the "--prune=all" on "git gc", otherwise it
will only delete stuff more than 2 weeks old.

-David




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

Re: Switching from old git tree

[Kenneth Raeburn]

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

Re: Switching from old git tree

[Eli Zaretskii]

> From: Kenneth Raeburn <raeburn@raeburn.org>
> Date: Sat, 15 Nov 2014 03:43:05 -0500
> 
> After creating your "main" clone of the new upstream repository, clone *that* one locally (use the "-s" option to save disk space)

Careful: kids are listening!  The -s option to clone has a caveat on
its man page, which, to me sounds as "Kids, don't try this at home!"

Re: Switching from old git tree

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kenneth Raeburn <raeburn@raeburn.org>
>> Date: Sat, 15 Nov 2014 03:43:05 -0500
>> 
>> After creating your "main" clone of the new upstream repository,
>> clone *that* one locally (use the "-s" option to save disk space)
>
> Careful: kids are listening!  The -s option to clone has a caveat on
> its man page, which, to me sounds as "Kids, don't try this at home!"

-s does not save disk space over the default _unless_ your local clone
happens to be on a different file system.  There is little reason to
keep local clones on different file systems, however.  On the same file
system, the normal git clone operation uses hard links, and those are
unproblematic regarding the given caveat.

-- 
David Kastrup

Re: Switching from old git tree

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 15 Nov 2014 10:18:19 +0100
> 
> On the same file system, the normal git clone operation uses hard
> links, and those are unproblematic regarding the given caveat.

Of course they are unproblematic: hard links are the default if -s is
_not_ used.  I was talking only about the suggestion to use -s.

Re: Switching from old git tree

[Ken Raeburn]

On Nov 15, 2014, at 04:18, David Kastrup <dak@gnu.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: Kenneth Raeburn <raeburn@raeburn.org>
>>> Date: Sat, 15 Nov 2014 03:43:05 -0500
>>> 
>>> After creating your "main" clone of the new upstream repository,
>>> clone *that* one locally (use the "-s" option to save disk space)
>> 
>> Careful: kids are listening!  The -s option to clone has a caveat on
>> its man page, which, to me sounds as "Kids, don't try this at home!"
> 
> -s does not save disk space over the default _unless_ your local clone
> happens to be on a different file system.  There is little reason to
> keep local clones on different file systems, however.  On the same file
> system, the normal git clone operation uses hard links, and those are
> unproblematic regarding the given caveat.

I'd forgotten that hard links were the default, I was thinking it would copy the needed objects. Even so, the disk space usage would have only been temporary, for the life of the repository used for merging. Yes, leaving out -s is probably the right thing in most cases.

But the general idea of using a second, temporary repository for the merging, and pushing only the updated branches back to the main repository, will save space in the long run, and without needing the 30-day delay, GC, etc. It also lets one start practicing pulling and pushing changes between repositories.

Ken