On Jan 26, 2012, at 2:54 PM, Lluís Batlle i Rossell wrote:
> On Thu, Jan 26, 2012 at 02:51:04PM -0500, Richard Hipp wrote:
>> On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski
>>> http://nuclearsquid.com/writings/git-add/
>>>
>>> Any opinions?
>>>
>>
>> I'm of the old-fashioned opinion that you ought to test your code before
>> you check it in.
>
> Very well explained! I totally agree.
>
> I imagine that in git, users are expected to commit wrong untested code (thus,
> that may not match the commit log), and some minutes later, edit all the
> history
> to make up. Also not testing the rewrites, of course. The git workflow.
Hm. I don't think that committing a partial file means you have not tested the
code. Take for example my previously stated example, a file named math.b
func add(a,b)
return a * b
end
func sub(a,b)
return a - b
end
-- New feature, multiplication
func mul(a,b)
return a * b
end
While editing I see that add is using multiplication! Doh! I whip up a few unit
tests:
test_equal(add(1,1), 2)
test_equal(add(5,5), 10)
Great, all passes. My math expansion, however, is not done. I still need to add
the requested division method and other branches can benefit from my "add" fix,
but the new math expansion still needs quite a bit of testing, peer reviews,
etc… So, I want to make my "add" bug fix available as a simple commit that can
be pulled.
So, I commit just a section of math.b, and math_tests.b.
Jeremy
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
