Re: [BUG/PATCH] t9350-fast-export: Add failing test for symlink-to-directory

[Jeff King <peff@peff.net>]

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

> On Fri, 21 Aug 2015, Jeff King wrote:
> >   - 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