Contents conflict from fast-import when files were renamed

[vila]

>>>>> Eli Zaretskii <eliz at gnu.org> writes:

<snip/>

    > These conflicts are already strange, since the diffs between these
    > files are in a single Copyright line (2011 was added to copyright
    > years in the upstream).  I tried to resolve them anyway, but that
    > failed:

    >   bzr resolve --action=take-other doc/idutils.texi
    >   bzr: ERROR: Tree transform is malformed [('duplicate', 'new-2', 'new-48', u'idutils.texi')]

    > (Btw, the docs says to submit a bug report about this kind of failure;
    > should I, given what's below?)

Yes please if you're using a version recent enough. Otherwise, check
that newer versions don't fix this (it may be http://pad.lv/529968 or
http://pad.lv/638451).

If you file a bug, having access to your repo will immensely simplify
diagnosis and fix.

    > "bzr mv", which should be identical according to docs, also failed:

    >   bzr mv doc/idutils.texi.OTHER doc/idutils.texi
    >   bzr: ERROR: Could not move idutils.texi.OTHER => idutils.texi: doc/idutils.texi is already versioned.

Hmm, I think you should 'bzr rm' idutils.texi first (imbw) but
--take-other should do the right thing for you. If it doesn't, it's a
bug.

    > The reason for this is probably the fact that in the upstream these
    > two files were originally called doc/id-utils.texi and
    > doc/id-utils.el.  They were renamed to idutils.* in the git repo, but
    > because git doesn't track renames, in the fast-import'ed `trunk'
    > branch it looks like the original files were deleted and then added
    > under the new names:

Yup, same path, different file-ids, as Eric said in his reply, there are
various ways to fix this issue, none of which received enough love
unfortunately :-/

    > I guess this made these files have different IDs, thus the conflicts.

Exactly. The infamous hole in the rename tracking :-/

    > My question is: how can I resolve this kind of conflict, without
    > losing the full history of these two renamed files?

That's another way to address the issue (not mentioned by Eric) and
harder to implement (the so-called file tokens) so both the histories
can be preserved. It's not implemented yet and a limitation of the
current model.

For now, you have to choose which history you want to keep (one should
be far more complete than the other hopefully[2]).

    > Also, shouldn't the fast-import plugin provide a way of generating
    > bzr renames while importing from git repositories in such cases,
    > in the first place?

This is probably the way to go (taking into account Eric's remarks about
a way to let the user decide[1]).


  Vincent

[1]: With additional bonus points for a persistent implementation so you
don't repeat yourself when fast-importing repeatedly.


[2]: These collisions on file-ids are rarely encountered (to the best of
my knowledge[3]) and the most common ones came from devs exchanging patches
without using a common branch which is generally for a short period of
time as far as the given file is concerned.

[3]: Excluding parallel imports where the files come from two branches
which have different histories *because* they are involved in loosely
coupled workflows (think upstream branches and packaging branches where
the later import tarballs instead of VCS data).