From: Elijah Newren Date: Mon, 06 Apr 2026 21:44:05 GMT Subject: Re: [WIP PATCH] fast-export: emit deletions first Message-ID: In-Reply-To: <20260406212937.GA30202@coredump.intra.peff.net> On Mon, Apr 6, 2026 at 2:29 PM Jeff King wrote: > > 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). Would re-ordering on fast-import's side introduce bugs or violate user's assumptions? Right now, fast-import has no check to prevent more than one command for the same pathname being given, and has a last-entry-wins ruling. Thus filemodify PATH followed by filedelete PATH gives different results than reversing the order. Most probably wouldn't care or want to ever do that, but I could see it as a way of allowing you to change your mind in the stream and override an earlier directive you sent. Further, from this paragraph: ``` Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`, `filedeleteall` and `notemodify` commands may be included to update the contents of the branch prior to creating the commit. These commands may be supplied in any order. However it is recommended that a `filedeleteall` command precede all `filemodify`, `filecopy`, `filerename` and `notemodify` commands in the same commit, as `filedeleteall` wipes the branch clean (see below). ``` the comment about ordering with `filedeleteall` does suggest that ordering matters to fast-import and thus perhaps that we shouldn't be messing with the order the stream-writer gave us. On the creator side, I agree that fast-export would definitely want to sort its deletes before modifies to avoid D/F conflict issues. That doesn't help with renames, but I agree with you that the answer for renames is probably "then don't do that."