Contents conflict from fast-import when files were renamed

Eli Zaretskii eliz at gnu.org
Sat Mar 26 20:15:09 UTC 2011


> From: Eric Siegerman <lists08-bzr at davor.org>
> Date: Sat, 26 Mar 2011 12:12:05 -0400
> 
> ISTM that if git isn't going to provide any hints about renames,
> fast-import would have to heuristically deduce them.  Never mind
> that the "mv --auto" logic is flawed, as we were discussing
> recently; even the better logic from the "automv" plugin is
> imperfect, as an heuristic must be.  The problem, AIUI, is that
> fast-import creates Bazaar revisions directly; thus, you don't
> get a chance to clean up the heuristic's inevitable wrong guesses
> before committing, as you do with an explict "mv --auto" or
> "automv" in your working tree.

I understand the difficulties during the initial import.  But at least
for subsequent imports, there could be an option through which the
user could submit a file with known renames, and then fast-import
could use these known renames to avoid conflicts.  Or, better,
fast-import could look for renames in the target bzr repo and
automatically cater to them.  Then the user could manually restore the
renames after the initial import, like I did, and have those renames
persist afterwards.

> Does bzr-git deal with the rename problem?

I don't know.  I cannot test this with the same repository, because
bzr-git bails out saying that it needs nested trees.



More information about the bazaar mailing list