Git feature request: --amend older commit

With git's "commit frequently" style, I often find that I end up with a commit that includes a typo in a comment or I forgot one call site when updating functions or something.

And it's a few commits later before I notice the simple oops.

This is of course fixable by making a commit, rebase -i HEAD~4 (or whatever), and marking the fixup for squashing into the previous commit.

But it would be really handy if there were a one-step command for doing this.

Something like "git commit --fixup HEAD~3", where "git commit --fixup HEAD" would be equivalent to "git commit --amend".

It would be fine if it were implemented using rebase -i and you had to use "git rebase --continue" to recover from a conflict. And history had to be linear from the fixup point to HEAD.

The only thing I'd wish for, that rebase -i doesn't support, is a commit with a dirty tree. (Because often the typo is noticed in the middle of further development.) But if I have to manually stash & pop, that would be good enough.

Talking with some friends, they all say "yeah, I would really use that feature". So I figured I'd mention it here.

On 08/17/2012 05:47 PM, George Spelvin wrote:

Have you tried "git rebase --autosquash"? It does part of what you are asking for and additionally allows multiple fixup commits to be queued up and processed in a single rebase.

Michael

No, I hadn't! It's not *quite* as simple as what I had hoped for, but definitely is progress in that direction.

In particular, I can probably manage to use those to write a script that does what I want. Something that ends up with something like "EDITOR=/bin/true git rebase -i --autosquash $base"

Thanks you! I apologize for my failure to (Re-) RTFM. I have done so numerous times, but the feature wasn't there last time I looked.

"George Spelvin" <linux@horizon.com> writes:

[...]

Umm, --fixup is already taken and makes the subject be 'fixup! <subject of argument>'. This can then be used by rebase -i --autosquash (or rebase.autosquash=true) to automatically put the fixup(s) that have accumulated into the right places. In addition, git-rebase learned to automatically use the upstream as the default base.

So for me it's usually a matter of

  git add -p
  git commit --fixup=...
  # repeat the above two until all fixups are lined up
  git rebase -i
  # close editor without making changes

Is that still too much effort?

<plug mode=shameless>

The ideas discussed in
  http://thread.gmane.org/gmane.comp.version-control.git/202535/focus=202569
also help selecting the fixup argument more quickly.

</plug>

On Fri, Aug 17, 2012 at 11:47:49AM -0400, George Spelvin wrote:

Aside from the ways others mentioned on how to do this, I think that a better interface if this were to be added would be to make the commit an optional parameter of --amend. Adding another parameter which effectively does a superset of --amend sounds unnecessary.

I often want to amend a commit, but its simply too much work, so I usually commit it marking the message as something like "fixup! ...". Then, before I push, I make sure to rebase all of the commits marked as fixups. Clearly autosquash does this, but to have to override the editor as "true" is just a hassle.

I feel like this is a common enough need that it deserves more first class support than relying on the rebase command and then using true as an editor. Either it should be supported natively or it should be possible to autosquash a rebase without --interactive, since at present --autosquash requires --interactive, which isn't nice for when the user does not want the rebase to be interactive. Such a simple task shouldn't require an interactive command.

Jared Hance <jaredhance@gmail.com> writes:

[administrivia: do not deflect a direct response to you away by using mail-followup-to header, thanks]

Yes, as an end-user facing command set, "git commit --amend HEAD~3" would not be a bad addition.

In some cases, yes. But the devil is in the details, and whoever wants to work on must be prepared to see cases where the remainder of the commits after rewriting an older commit will not replay cleanly on top of it. At that point, it won't be a simple task anymore. At least, it must make it clear what the user should do when "commit --amend HEAD~3" (and subsequent rebuilding of HEAD~2, HEAD~1 and HEAD on top of the amended result) needs a help from the user to resolve conflicts. It may be just the matter of mentioning "from here on, follow the procedure you would use when you are running 'rebase -i'", if the chosen mechanism to implement the sequencing behind the "commit --amend HEAD~3" UI is "rebase -i".