Johannes Schindelin wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html