> Do people have any feelings or conventions for how and when to > publish a series of commits where the first one(s) break something > and the next ones clear it up? I'm curiuos, why to you want to commit changes that break something separately from fixup? Many conventions (as I know) use ideology that every commit must NOT BREAK existing code or tests. Every SHARED commit. Git design (as you must be already know) allows you to make/change/reorder as many commits as you want (before you share them or push to a "central" repository). So, you have not to be afraid to commit every your change, because you can always change/fixup/split your commits. Usually, you introduce a feature in a branch. Also, your project must have (?) (mine do have) unit-tests, at least. And most changes must be tested. So, breakage must be discovered early, even after some other commits in that feature branch. In that case you can just make a fixup commit and then rebase it on a breakage commit with a "squash". And only after all features made and all tests passed you can share them (push to another repo). >I've found some discussion, but with vague results. > > I'm about to commit some small edits which go together with bigger > generated changes. It seems both more readable and more cherry-pick- > friendly to me to keep these in separate commits. > > What I've found is I can use a line in the commit message like > "Incomplete change, requires next commit (update foo/ dir)." > and, if there is any point, do a no-ff merge past the breakage. > -- 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