Re: [PATCH 0/2] builtin/history: introduce "fixup" subcommand

[Patrick Steinhardt <ps@pks.im>]

On Thu, Apr 23, 2026 at 02:18:16AM +0800, Tian Yuchen wrote:
> Hi Patrick,
> 
> On 4/22/26 18:28, Patrick Steinhardt wrote:
> 
> > Hi,
> > 
> > this short patch series introduces a new "fixup" subcommand. This
> > command is the first one that I felt is missing in my day to day work,
> > as I end up doing fixup commits quite often.
> > 
> > The flow is rather simple: the user stages some changes, and then they
> > execute `git history fixup <commit>` to amend those changes to the given
> > commit. As with the other subcommands, dependent branches will then be
> > rebased automatically.
> > 
> > This is the first command that may result in merge conflicts. For now we
> > simply abort in such cases, but there are plans to introduce first-class
> > conflicts into Git. So once we have them, we'll also be able to handle
> > such cases more gracefully. I still think that the command is useful
> > even without that conflict handling.
> 
> Thank you for developing this feature. Godsend for lazy people like me ;)
> 
> Nevertheless, I seem to have come across what appears to be a bug. I carried
> out the following steps:
> 
> 	create a.txt -> git add -> git commit -m "base" ->
> 
> 	create b.txt -> git add -> git commit -m "feature" ->
> 
> 	create c.txt -> git add -> git commit -m "tip" ->
> 
> 	rm b.txt -> git add ->
> 
> 	git history fixup HEAD~ ->
> 
> 	git log --oneline --stat...
> 
> And the output looks like:
> 
> 	3096a65 (HEAD -> master) tip
> 	 c.txt | 1 +
> 	 1 file changed, 1 insertion(+)
> 	699f610 feature
> 	0be07e6 base
> 	 a.txt | 1 +
>  	1 file changed, 1 insertion(+)
> 
> More specifically, the output of
> 
> 	git show HEAD~
> 
> is:
> 
> 	Author: Tian Yuchen <cat@malon.dev>
> 	Date:   Thu Apr 23 01:57:17 2026 +0800
> 
>  	   feature
> 
> which is an empty commit. Is it what we expect to see? Sorry that I don't
> have enough time to look at the code in detail :P

I guess the answer is "maybe". I think it would most sense if we had the
equivalent of `--empty=(drop|keep|stop)` that we also have in
git-rebase(1).

Thanks!

Patrick