On Fri, Aug 21, 2015 at 12:47:30PM -0400, Anders Kaseorg wrote:

On Fri, 21 Aug 2015, Jeff King wrote:

quoted

  - we may still have the opposite problem with renames. That is, a
    rename is _also_ a deletion, but will go to the end. So I would
    expect renaming the symlink "foo" to "bar" and then adding
    "foo/world" would end up with:

       M 100644 :3 foo/world
       R foo bar

    (because we push renames to the end in our sort). And indeed,
    importing that does seem to get it wrong (we end up with "bar/world"
    and no symlink).

We can't fix the ordering in the second case without breaking the first
case. So I'm not sure it's fixable on the fast-export end.

Hmm, renames have a more fundamental ordering problem: swapping two 
(normal) files and using fast-export -C -B results in

  R foo bar
  R bar foo

which cannot be reimported correctly without fast-import fixes.

Yeah, you're right. Fast-export's view of the world comes from diff,
which is that the "source" side is immutable. Whereas fast-import seems
to mutate the tree in-place as it reads the set of operations. I wonder
what would break if we simply fixed that. I.e., is anybody else
depending on:

  R foo bar
  M bar ...

to modify "foo" and not "bar". I kind of wonder if it is insane to turn
on renames at all in fast-export.

-Peff