Johannes Schindelin wrote:
But how do you make sure that it works as expected? I.e. when you commit a hunk using, say, variable "rule_the_world", and by mistake (happen to me all the time, maybe to you, too?) forgot to select the hunk which declares that variable, maybe because it is hidden in a forest of other variables?
For cases like that, sure, partial commits are dangerous. On the other hand, I've sometimes done partial commits for things like correcting erroneous comments in code I'm working on, where there is no functional change whatsoever in the hunk I'm committing and where I want to isolate the corrections from the functional changes I *am* working on.
Also, when I'm working on a topic branch in my local sandbox I like to do lots of work-in-progress commits. I usually do those based on the granularity of my mental model of what I'm working on, and I have no expectation whatsoever that any particular percentage of them represent working code or even code that compiles. Sometimes I do partial commits in that situation too: I make a change to some function in a file that I'm editing elsewhere, and commit just that hunk with a commit log message reminding me of why I made the change. Those commits are not intended for public consumption; they're just to help me keep track of my own work. Once everything is in a working state, I do a squash merge or a bunch of cherry-pick -n invocations to build some revisions to publish to the outside world, and *then* I am in "each commit must represent a non-broken state" mode.
The great thing about git (well, *one* of the great things) is that it unifies those two workflows in one system. With, say, svn, the "lots of little checkpoints of my work in progress" part of that is awkward at best, because it's very much oriented around an "if the version control system knows about a change, it is by definition published to the outside world" model.
So I guess my point, after all that, is just that assumptions that are valid in the context of one workflow are not necessarily as valid in others, and that even in a particular context, not all changes are created equal.
-Steve - 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
