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

From: Steffen Prohaska <prohaska@zib.de>
Date: Jun 24, 2007, 20:54 UTC
Message-ID: <6382A127-7A81-4ADE-B2C1-1FCCBE9EA239@zib.de>
In-Reply-To: <20070624183552.GA2374@steel.home>

On Jun 24, 2007, at 8:35 PM, Alex Riesen wrote:

Show 5 quoted lines

> Your script works, just it can be made simplier: no need for diff,
> it'll only hurt perfomance and complicates things. And you don't have
> to care about additions/deletions, and it is trivially extensible to
> support merges, and the current index is untouched - your user can
> continue working in predictable environment.

I understand that I can leave the default index untouched by using a different index. I knew that this must be possible somehow but was too lazy to find out how. Thanks for the details.

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.

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.

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

> BTW, Johannes moved that ident code you copied from git-filter-branch
> into its own shell file, so it can be sourced and trivially reused.

I see, thanks.

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.

	Steffen