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