Re: [boost] [Git] Moving beyond arm waving?

Subject: Re: [boost] [Git] Moving beyond arm waving?
From: David Bergman (David.Bergman_at_[hidden])
Date: 2011-02-02 14:01:46

On Feb 2, 2011, at 12:41 PM, Rene Rivera wrote:

> On 2/2/2011 11:30 AM, Steven Watanabe wrote:
>> AMDG
>> 
>> On 2/2/2011 7:44 AM, Beman Dawes wrote:
>>> To move discussion of Git beyond the arm waving stage, I'd like to
>>> suggest several concrete steps:
>>> 
>>> * Use the tag "[git]" to identify list postings discussing integration
>>> of Git into Boost daily life. If that gets unwieldy, we can start a
>>> separate mailing list.
>>> 
>>> * Start building documentation, with a lot of the initial effort going
>>> into rationale and "how to do it". To that end, I've started to
>>> populate a "Git" hierarchy on the Trac wiki:
>>> https://svn.boost.org/trac/boost/wiki/Git/GitHome. Please contribute!
>>> 
>> 
>> The advantages look like a good start. I'd like
>> to add:
>> 
>> Con:
>> * The migration itself will cause a certain amount of disruption
>> (transient)
>> * Those who just don't care will have to learn a new tool
>> (transient, subjective).
>> * Links to svn will be broken. Trac and svn are currently
>> heavily cross-linked. If someone has a way to avoid this
>> problem, I'd be more than happy to withdraw it. (long-term).
> 
> If you want more criticism of Git.. You might want to read through the docs for Fossil <http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki>. Ostensibly a better VCS, IMO ;-)

I like Fossil, and have used it in some projects lately, instead of a GitHub solution. The whole idea of having commits, tickets and documentation (Wiki) in the same repository is quite attractive.

What I do not agree with in the their claims is that it is easier to handle than Git. Git is *conceptually* extremely simple, which is the beauty of it: a heap of two types of objects - commits and file trees - related in a DAG, where the branches and tags are just pointers to those heap-based objects. And this goes for everything in Git, including the "staging area" used and the (extremely useful for real world development) "stash" areas. I have never seen such conceptual clarity in a VCS - well, outside Darcs' patch theory, but patches are simply inferior to snapshots, for stability and performance-related reasons, IMHO. It is "just" that Linus (and others) created a host of convenience tools on top of that simple "DAG file system" ;-)

I do not see that simplicity in Fossil, really, but perhaps my vision is blurred somewhat by the goodies entangled into it, in the form of the aforementioned tickets and Wiki? And the separation of source tree (or working directory) and the local repository in Fossil adds complexity with another SQLite database containing the "staged" changes.

What is really cool about Fossil is that it is a one stop solution for a lot of projects, and that one can deal with tickets while offline, even changing their states.

/David