Nirbheek Chauhan <nirbh...@gentoo.org> posted 8b4c83ad0907222009sba2c36fu59d2caf68ebcf...@mail.gmail.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
