Controvery over commit styles

Posted May 27, 2010 15:14 UTC (Thu) by JohnLenz (guest, #42089)
In reply to: Controvery over commit styles by epa
Parent article: Interesting times for Linux Flash support

IMO for a distributed revision control there is even more pressure to make sure each commit is a working piece of code. The reason is bisection: once you switch to a distributed revision control you can start to use bisection to find problems, but bisection fails (or at least makes your life more complicated) if there are intermediate commits which are broken in some way.

Especially the test suite breaking in a commit, because the test suite failures would be what you probably would be bisecting.

Micro-commits versus non-regressive commits

Posted May 27, 2010 16:33 UTC (Thu) by alex (subscriber, #1355) [Link]

Sure the pressure for good working atomic commits is high when you can have working bisection in a DVCS. This is a good thing.

However I've often noticed with central VCS systems the pressure to commit before your set of disparate changes become too extensive.

Using a DVCS can alleviate that pressure by allowing you to develop locally with multiple small commits. Once you've fixed your regressions you can re-base into nice tidy commits, re-test and then push to the public repository.

AIUI Gnash is already using Bazaar so it really should be possible to have a clean commit history without breaking stuff on the way.

Controvery over commit styles

Posted May 27, 2010 17:01 UTC (Thu) by hmh (subscriber, #3838) [Link]

Yes, you're correct. On the other hand, there are already numerous tested and proven workflows to implement both the bissectability and clean history, AND allow for the work-in-progress dirty history.

In the simpler one, you use at least two work branches, plus the mainline branches. You move the ready-and-tested work from the dirty work branch to the mainline through an intermediate cleanup branch. The no-mess, no-regression, clean history for bissectability requirements exist only in the mainline and intermediate cleanup branches.

Controvery over commit styles

Posted May 28, 2010 9:20 UTC (Fri) by marcH (subscriber, #57642) [Link]

If your changes are so disruptive that they need to break the test suite then you should simply work in a isolated branch, so other developers can keep working. Distributed version control makes that easier but is not strictly required.

That such engineering basics are unknown to the Gnash developers says a lot about the project.

There is LESS pressure in distributed revision control to make sure each commit is a working piece of code, since it is much easier to rewrite history and get rid of such "breaking" commits later.