On Aug 6, 2007, at 2:22 AM, Johannes Schindelin wrote:

quoted text
> On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>
>> I found it quite useful to be able to commit diff chunks selectively.
>
> 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?

In various ways, the details depend on what I'm doing. Here are three
examples.

1) I push the commit to a faster machine to compile it there and  
continue
working on the next commit (a complete build of the software package  
that
I'm mostly working on takes approximately 30 min on our fastest  
machines. I
can't wait for this before I continue working. Luckily a complete  
compile is
rarely needed).

2) I don't care about a single commit. I only care about the result of a
series of commits. I need to check on multiple architectures anyway  
and can't
thoroughly test what I'm doing right now. Regularly gcc and Microsoft
compilers disagree on warnings.

3) I push a series of commits to my scratch space and wait one night  
for the
automated builds to complete on all architectures.

quoted text
> I _try_ to test commits by my eyes, by compiling, and by running the
> version I'll commit.  (Okay, sometimes I run the test _after_  
> committing,
> but then I test to see if I have to amend something.)

Option (1) is probably the only solution that fulfills your  
requirement that
every single commit should compile and work. This is a perfect  
approach but
sometimes take too much time for me.

	Steffen


-
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