From: Steffen Prohaska <prohaska@zib.de>
Date: Sun, 24 Jun 2007 09:05:29 GMT
Subject: Re: [PATCH] transplant: move a series of commits to a different parent
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:

> 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