Re: [PATCH] transplant: move a series of commits to a different parent

From: Steffen Prohaska <prohaska@zib.de>
Date: Jun 24, 2007, 09:05 UTC
Message-ID: <4D530871-0CBE-4F9A-99B7-ECF0F4656D85@zib.de>
In-Reply-To: <20070624082906.GB2467@steel.home>

On Jun 24, 2007, at 10:29 AM, Alex Riesen wrote:

Show 17 quoted lines

> Steffen Prohaska, Sat, Jun 23, 2007 21:27:57 +0200:
>> +for commit in $(git-rev-list --reverse $from..$to)
>> +do
>> +    echo "rewriting commit $commit..."
>> +    git-diff-tree -r $commit | grep ^: | cut -b 9-15,57-97,100- |
>> +    while read mode sha path
>> +    do
>> +        echo " $mode $sha $path"
>> +        git-update-index --add --cacheinfo $mode $sha $path
>> +    done
>
> Why not just read-tree for every commit? It is not like you're
> modifying the repository in any way, just changing parenthood. That'd
> solve the problem with deletions.
> So it should be enough to read-tree the repo state for each and every
> source commit into the index (and you can just use a temporary index
> file for that, see GIT_INDEX_FILE). Than just commit the index.

I am changing the repository.

I only modify the index for files that have changes in $commit. Their content gets replaced by the content from the commit. I'm leaving all other files untouched.

This creates a new series of commits that starts from the repository state of <onto> and has mixed in files only if they are changed in the series of commits from..to. These files are just replaced. I'm not trying to merge changes but just replace the whole file.

Opposed to that, read-tree would modify the content of _all_ files.

Here's the situation before transplant

           o--Y--3
          /
   1--X--2--o--o--o

Say at X the file x.txt got modified. At Y the file y.txt got modified. 3 has both modifications.

Now I do transplant 1 2 3, which yields

     o--Y--4
    /
   1--X--2--o--o--o

y.txt is identical in 3 and 4 but x.txt is identical in 1 (!) and 4. Hence 3 and 4 are different. The changes to x.txt in commit X got eliminated from the history. 4 is a mixture of 1 and the repository state of files at 3 that got modified between 2 and 3. Changes between 1 and 2 got eliminated from the history.

This is exactly what I want to achieve. The content of the files on branch 3 is correct for all files that were committed after 2. But because 2 is the wrong branching point all the content originating from commits between 1 and 2 is wrong. Files committed between 2 and 3 have the right content but the branch needs to be attached at 1.

	Steffen