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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
