[gentoo-dev] Re: Progress on Universal Select Tool

[Duncan]

Nirbheek Chauhan <nirbheek@g.o> posted
8b4c83ad0907222009sba2c36fu59d2caf68ebcfd95@××××××××××.com, excerpted
below, on  Thu, 23 Jul 2009 08:39:00 +0530:

> 2009/7/23 Sérgio Almeida:
>> I'm still not doing any commits as uselect can still break your python
>> environment while testing and i don't have the time to learn how to
>> handle branches in git.

> It's probably wise to commit code in small-ish (and self-containing)
> discrete units each of which add something without breaking anything.
> Otherwise, it becomes very difficult to track down which change broke
> something via git bisect. I would recommend that you try to do this, if
> only just to learn how to make good commits.
>
> You could take a look at how the kernel folks handle this -- features go
> in as several small commits/patches.

As a non-dev direct git kernel tester and bug filer that now regularly 
bisects new bugs I find down to the individual commit, absolutely 100% 
agreed.  It's SO much easier for even a non-dev to properly test and 
bisect a properly commit unitized git source, than it was to do it 
manually, before, and the quality of my bugs and the resolutions thereof 
well demonstrate that fact.

While git branches are FWIW trivial, if you don't want to deal with them 
ATM, don't.  Just get the unitary commits right, and use tagging to 
demarcate points where you believe it's stable enough to test.  The rest 
will come, in time.  (Again, I say this as a non-dev, but even tho I'm 
not a dev and don't fully understand git myself, in git, branching 
really /is/ trivial, even for non-dev testers. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman