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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jun 24, 2007, 22:20 UTC
Message-ID: <20070624222039.GB2374@steel.home>
In-Reply-To: <6382A127-7A81-4ADE-B2C1-1FCCBE9EA239@zib.de>

Steffen Prohaska, Sun, Jun 24, 2007 22:54:21 +0200:

> I don't see how I can avoid tree diffs. As I pointed out earlier I need
> to mix the tree of the base commit of the newly built branch with
> files that were changed in the series of commits that I'm transplanting.

Hmm...

Show 5 quoted lines

> Just taking the whole tree from the commits I'm transplanting is  
> _wrong_.
> I need to only take files that were touched by a commit. The tree of
> the tip of the resulting branch can be quite different from the tree
> of the tip of the original branch.

I see.

Show 5 quoted lines

> >As to perfomance: read-tree doesn't actually _read_ the blobs to
> >populate index, just the trees. And diff-tree has do do the same, but
> >also _compare_ two trees recursively: more work, more memory needed.
> 
> I'm still pretty convinced that I need tree diffs (not file diffs!).

"git-read-tree --reset" does an in-index merge (just discards unmerged entries), so it still is better then git-diff-tree. But remove that unlink, so that the previuos tree is not discarded and do a "git-read-tree $onto" before starting the loop.

Show 9 quoted lines

> Anyway, the script worked for me and I still think it may be useful for
> fixing broken repositories resulting from a wrong cvsimport. I would
> probably improve many details if someone else considered my work useful.
> But up to now it seems as if I failed to explain, why the script would
> be needed in the first place.
> 
> However, the best way would be to fix git-cvsimport to handle branches
> correctly independently of the time of the first commit to a branch;
> and avoid insane, broken repositories altogether.

You still better make it work properly wrt deleted files. And you have to be careful not to hit a real content conflict.