Re: git: uh-oh - Mailing list pgsql-hackers

From Michael Haggerty
Subject Re: git: uh-oh
Date
Msg-id 4C6C03AC.8000204@alum.mit.edu
Whole thread Raw
In response to Re: git: uh-oh  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: git: uh-oh
List pgsql-hackers
Alvaro Herrera wrote:
> Excerpts from Michael Haggerty's message of mié ago 18 05:01:29 -0400 2010:
> 
>> [...]  Alternatively, you
>> could write a tool that would rewrite the ancestry information in the
>> repository *after* the cvs2git conversion using .git/info/grafts (see
>> git-filter-branch(1)).  Such rewriting would have to occur before the
>> repository is published, because the rewriting will change the hashes of
>> most commits.
> 
> AFAICT, graft points are not checked in[1], thus they don't propagate; are
> you saying that we should run the migration, then manually inject the
> graft points, then run some conversion tool that writes a different
> repository with those graft points welded into the history?  This sounds
> like it needs some manual work (namely find out the appropriate graft
> points for each branch), that can be prepared beforehand.  Otherwise it
> seems easier than reworking the cvs2git code for the "mostly-exclusive"
> option.

It is true that grafts are not propagated, but they can be baked into a
repository (at the cost of rewriting the SHA1 hashes) using "git
filter-branch".  The procedure would be as follows:

1. Convert using cvs2git

2. Create a file .git/info/grafts containing the changes that you want
to make to the project's ancestry.  The file has the format
   commit parent0 parent1 ...

where each of the entries is a SHA1 hash from the existing repository.
Only commits whose parentage should be changed need to be mentioned.
This is the tricky step because it requires some logic to decide what
needs changing.  And it can only be done after the cvs2git conversion,
because it requires the SHA1s resulting from the conversion.

3. Run
   git filter-branch

This rewrites the commits using any parentage changes from the grafts
file.  This changes most commits' SHA1 hashes.  After this you can
discard the .git/info/grafts file.  You would then want to remove the
original references, which were moved to "refs/original".

4. Publish the repository.

As long as the repository is only published after the grafts have been
baked in, there is no reason that anybody else would need the grafts file.

Michael


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: git: uh-oh
Next
From: Michael Haggerty
Date:
Subject: Re: git: uh-oh