> >> * 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!". You guys probably already know about it, but there is `git commit --fixup SHA1` to create !fixup commits intended for a particular commit. I think using this feature solves all the problem the OP has? Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html