From: Farid Zakaria Date: Mon, 13 Jul 2026 16:30:40 GMT Subject: Re: [PATCH v3] sequencer: honor --empty when a fixup!/squash! empties its target Message-ID: In-Reply-To: <7a1e5111-185e-4390-afa1-c19908c9bd86@gmail.com> On Mon Jul 13, 2026 at 6:18 AM PDT, Phillip Wood wrote: > On 12/07/2026 06:01, Junio C Hamano wrote: >> Farid Zakaria writes: >> >>> When "git rebase --autosquash" melds a "fixup!" or "squash!" commit into >>> its target, the result can be a commit that no longer changes anything >>> relative to its parent, for example when the melded change reverts the >>> target. Rather than dropping or keeping this empty commit, the rebase >>> stops with >>> >>> You asked to amend the most recent commit, but doing so would >>> make it empty. ... >>> >>> and the "--empty" option has no effect on it. This makes backing a >>> change out of a series awkward: reverting a commit as a "fixup!" and >>> running "git rebase --autosquash --empty=drop" ought to remove both the >>> commit and its revert, but it halts instead. >>> ... >>> Changes in v3: >>> * Switch the new tests' assertions from grep to test_grep for better >>> diagnostics (per review). >>> * Link to v2: https://lore.kernel.org/r/20260710-fz-autosquash-empty-v2-1-fa1e277e05f8@gmail.com >> >> I see you are already working well with Phillip, which is great. >> >> This topic, when merged to 'seen', seems to have quite a lot of >> overlaps with his pw/rebase-drop-notes-with-commit topic. > > Oh, I should have thought of that > >> We are >> expecting the topic to be rerolled, and I was under the impression >> that the remaining issues in that topic were all minor (Phillip, >> correct me if I am wrong) and hopefully we will see it in 'next' >> not in so distant future. > > I've just sent a new version and cc'd Farid, I'll try and take look at > this patch tomorrow > Thanks for cc'd. I'm not familiar with the workflow (I read the docs) but is there an email reply when it's accepted into 'next' that I will just look-out for ? I'm not subscribed to the mailing list in general otherwise. >> So it might make sense for you to coordinate with Phillip, and wait >> for his topic to be merged to 'next'. After that happens, you would >> prepare a merge commit of the other branch into f85a7e6620 (Start >> Git 2.56 cycle, 2026-07-06) or some other stable point, and rebuild >> this patch on top of it. That way, it will be much less likely that >> I'd make stupid and unnecessary mismerges when attempting to >> integrate this topic into my tree. > > That makes sense, assuming no-one has any more comments on > 'pw/rebase-drop-notes-with-commit' it should in be 'next' fairly soon. > > Thanks > > Phillip Phillip, Let me know if you have any more comments. I suspect not much will changes logic-wise once I rebase it onto 'next'. For clarity, is the f85a7e6620 commit the 'next' branch ? I would have thought to just rebase ontop of 'next' and I'm a bit confused with this commit hash. If there is anything else I should be aware of, I would appreciate a CC if you can remember :) Thank you!