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