Re: How to commit incomplete changes?

From: Alexey Shumkin <alex.crezoff@gmail.com>
Date: Dec 15, 2011, 06:44 UTC
Message-ID: <20111215104444.783303cf@ashu.dyn1.rarus.ru>
In-Reply-To: <4cfc9cf0515b1bc751f6aa0de4f55e2a@ulrik.uio.no>

>  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).

Show 10 quoted lines

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