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