On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote: > On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov < > flatw...@users.sourceforge.net> wrote: > > > > > On the other hand, Git is not *that* hard to learn basic concepts, > > really. And it has external tools providing fancy GUIs, if needed. > > > > My argument goes like this: Every developer has a fixed number of "brain > cycles" to use on any given day. Some of this brain-energy must be > expended for overhead, such as finding ones way to the coffee machine, or > operating the version-control system (VCS). The fewer brain-cycles one has > to spend on the overhead functions, the more there are available for us in > writing code. > > The goal of Fossil is to require fewer brain-cycles. Fossil isn't > perfect. I'm sure there are things that can be done so that it requires > less effort. But I believe it is better than monotone, bzr, or hg, and way > better than git. > > Of all of the VCSes out there today, surely Git requires more daily > brain-cycles than any other. I'm not talking about just the learning-curve > here. Git requires more thought and attention even after you know it > well. And that extra thought and attention that you devote toward > operating Git could be better spent working on your project.
Interesting idea, this of brain cycles. :) I also find git particularly difficult. In the case of having two checkouts in two computers, it ends up scaling to 4 heads: local and remote head in each computer. And all operations (merge, fetch, ...) work updating references between those *4* heads, instead of 2. I find that with two checkouts, I shouldn't need graph operations between 4 heads. For me, it means double work. Regards, Lluís. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
