Re: A couple of rebase --autosquash proposals

From: Brett Randall <javabrett@gmail.com>
Date: Dec 9, 2013, 09:52 UTC
Message-ID: <CALeEUB5kaJ0j2qqzDN4ZcZbQ1W3Zttvmuqr73Jv+i79FM=b4eg@mail.gmail.com>
In-Reply-To: <52A58CBB.6040809@gmail.com>

This aims to support code-review workflows of teams that prefer rebase over merge, when committing a new peer-reviewed feature.

* Developer starts with commit OM, commits A.
* During testing, the developer may make further changes, either
through --amend or new commits, but either way, all work is rebased to
a single new commit for review, OM -> A' .
* A' is pushed as a new branch to origin for team review.  The review
system facilitates the review of the change, and review comments are
made.
* The developer responds to the review comments by making changes in
commits B and C, and pushes OM -> A' -> B -> C.  Reviewers can
understand the feedback that has been addressed in the changes with
through the commit-log in B and C.
* Code passes review.  Because the team prefers rebased commits, A'..C
is rebased onto the current OM (which may now be OM+10) and committed.

If the commit-log entries for B and C allow simultaneous fixup!/squash! syntax together with and free-text log-text, they can serve both purposes: 1) they communicate that the change is a feedback-generated fix (rather than a new feature), and describe which parts of the feedback each commit addresses, and 2) they pre-empt and support the eventual rebase-before-origin-push, through --autosquash annotation.

Brett

On 9 December 2013 20:26, Chris Packham <judge.packham@gmail.com> wrote:

Show 25 quoted lines

> On 09/12/13 19:51, Johannes Sixt wrote:
>> 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?
>
> In the past I've used this kind of approach when doing merging/porting
> work with 3rd party code (or just large integrations). The first (and
> eventually final) commit introduces the new code. The subsequent fixups
> address build issues which are either errors in the 3rd party code
> (which I will want to submit bug reports for later and carry in my tree
> as real commits) or errors in my merging (which I want to squash into
> the merge commit). When faced with a screen full of compilation errors
> I'm not sure which of these 2 categories are applicable at the time so I
> tend to have lots of little fixups that I need to juggle around with git
> rebase once I've got the code compiling and passing some tests.
>
> All that being said I think allowing multiple "fixup!\n" stack up on
> each other might be a bit dangerous. There are cases where
> fixup!-fixup!-real might be useful but those would be hard to
> distinguish those from cases where someone absent mindedly forgot to put
> something after "fixup!".