On Jun 24, 2007, at 8:35 PM, Alex Riesen wrote:
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
