Git feature request: --amend older commit

Git feature request: --amend older commit

[George Spelvin]

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.

Re: Git feature request: --amend older commit

[Michael Haggerty]

On 08/17/2012 05:47 PM, George Spelvin wrote:
> 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". [...]

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

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: Git feature request: --amend older commit

[George Spelvin]

> 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.

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.

Re: Git feature request: --amend older commit

[Thomas Rast]

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

> 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.
[...]
> 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".

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>

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Git feature request: --amend older commit

[Jared Hance]

On Fri, Aug 17, 2012 at 11:47:49AM -0400, George Spelvin wrote:
> Something like "git commit --fixup HEAD~3", where "git commit --fixup HEAD"
> would be equivalent to "git commit --amend".

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.

Re: Git feature request: --amend older commit

[Junio C Hamano]

Jared Hance <jaredhance@gmail.com> writes:

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

> On Fri, Aug 17, 2012 at 11:47:49AM -0400, George Spelvin wrote:
>> Something like "git commit --fixup HEAD~3", where "git commit --fixup HEAD"
>> would be equivalent to "git commit --amend".

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

> Such a simple task shouldn't require an interactive command.

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".