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
* 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
On 9 December 2013 20:26, Chris Packham <judge.pack...@gmail.com> wrote:
> 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
>> 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!".
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