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

[Tian Yuchen <cat@malon.dev>]

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

Thanks, Yuchen