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

From: Jeff King <peff@peff.net>
Date: Aug 24, 2015, 05:25 UTC
Message-ID: <20150824052548.GA14403@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.10.1508211238570.31851@buzzword-bingo.mit.edu>

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

Show 23 quoted lines

> 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