I had not previously noticed commit --fixup, so that is something
useful I have learned from this thread, thanks.

The workflow here can be summarized as "I have an initial commit and
subsequent, review-generated commits, that I'd like to share on a
review-branch with proper commit-log comments, but also pre-marked for
future --autosquash".  So when the review is completed, I can auto
squash/fixup all the review-generated commits and rebase onto
origin/master at the same time.  I find this more appealing than
continually pushing rebased branches to colleagues, as the history is
lost and it is hard to review incremental changes.

I can live with it as it is: I just use rebase -i and change all
review-generated commits pick -> r as if autosquash didn't exist.
It's just that when I first tried-out fixup!, I mistakenly thought
that I could use the first line as the special syntax, and use
following-lines as annotation - which is not the case, but I thought
it might be worth suggesting here.


On 10 December 2013 07:20, Junio C Hamano <gits...@pobox.com> wrote:
> Johannes Sixt <j.s...@viscovery.net> writes:
>> Am 12/9/2013 3:23, schrieb Brett Randall:
>>> * fixup! or squash! on it's own would default to fixing-up the
>>> previous commit (or result of previous step of rebase if that was a
>>> squash/fixup).
>> Why would you want that? To fixup the previous commit, just use 'git
>> commit --amend'. What am I missing?
> When you are not absolutely sure if the amend is a good thing to do.
> Then
>         work work work
>         git commit --fixup HEAD
>         work work work
>         git commit --fixup HEAD^
>         work work work
>         git commit --fixup HEAD^^
>         ...
>         git rebase --autosquash -i ...
> may become a good way to polish a single commit.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to