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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jun 24, 2007, 09:30 UTC
Message-ID: <20070624093017.GC2467@steel.home>
In-Reply-To: <4D530871-0CBE-4F9A-99B7-ECF0F4656D85@zib.de>

Steffen Prohaska, Sun, Jun 24, 2007 11:05:29 +0200:

Show 20 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.
>

No, you don't.

> 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.

No, you don't modify anything. Ever tried to run git-status after your script finished? Tried to understand what the output means?

Show 6 quoted lines

> 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.

No, it wouldn't (unless you run git-read-tree -u, and I fail to see why would you want that). You probably confuse git-read-tree with git-checkout-index.

Show 6 quoted lines

> 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.

This misses merges (see git-rev-list --parents), but does the job for linear history:

    export GIT_INDEX_FILE="$(git rev-parse --git-dir)/tr.idx"
    parent=$(git rev-parse "$onto")
    git rev-list --reverse "$from..$to" | while read c
    do
	rm -f "$GIT_INDEX_FILE"
	git read-tree $c || break;
	# Authorship information here
	parent=$(git cat-file commit $c | \
	    sed -e '1,/^$/d' | \
	    git commit-tree $(git write-tree) -p "$parent")
	echo "Commit $parent"
    done