Re: [WIP PATCH] fast-export: emit deletions first

From: Jeff King <peff@peff.net>
Date: Apr 6, 2026, 21:29 UTC
Message-ID: <20260406212937.GA30202@coredump.intra.peff.net>
In-Reply-To: <xmqqo6jwau34.fsf@gitster.g>

On Mon, Apr 06, 2026 at 10:15:27AM -0700, Junio C Hamano wrote:

> In any case, it is a bit surprising that fast-export survived this
> long without having encountering the problem you are solving.  I
> wonder if fast-import handles such an output with some smart to
> avoid the issue?

I think it has come up a few times, but we never actually applied a fix:

  2015: https://lore.kernel.org/git/alpine.DEB.2.10.1508191532330.31851@buzzword-bingo.mit.edu/
  2017: https://lore.kernel.org/git/1493079137-1838-1-git-send-email-miguel.torroja@gmail.com/
  2023: https://lore.kernel.org/git/BBB169A5-0665-47C9-819B-6409A22AB699@lanl.gov/

Looks like discussion got hung up on ordering other types of modifications, like renames (which can actually have cycles). But I don't see anything to contradict the view that putting deletions first solves real problems and would not harm anything. And the answer to "it hurts to fast-export with renames" is probably "don't do it".

It's also possible that sorting should be the responsibility of the receiver. I.e., should fast-import see:

  M 100644 :blob_label a/b
  D a

and figure it out? Or maybe we want both (to help other consumers of fast-export, but also to help fast-import when consuming output of other sources).

-Peff