Gentoo Archives: gentoo-user

From: Alec Ten Harmsel <alec@××××××××××××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Gentoo's future directtion ?
Date: Sat, 29 Nov 2014 17:21:39
Message-Id: 547A009E.1060704@alectenharmsel.com
In Reply to: Re: [gentoo-user] Re: Gentoo's future directtion ? by Alan Mackenzie
1 On 11/29/2014 09:28 AM, Alan Mackenzie wrote:
2 > Speaking as a developer in a project which has just converted to git, I
3 > can assure you that git has tremendous disadvantages, even compared with
4 > cvs.
5
6 It depends; they do different things. Depending on what I'm working on,
7 I use either subversion or git; neither is inherently better all the time.
8
9 >
10 > Principally, git does not have a high level model of version control
11 > concepts, so that using git is somewhat analogous to programming in
12 > assembler. Both give you tremendous control and the ability to do
13 > practically anything, including shooting yourself in the foot. So that
14 > instead of conceptualising a "branch" (as you would do with Mercurial,
15 > Bazaar, Subversion, or even CVS), you need to think about "commits
16 > reachable from a certain head (excluding commits reachable from some
17 > other head)".
18
19 As far as I can tell, git has a very clear concept of branching. Fast
20 branching was one of the biggest design points in git[1], and they did
21 it by merely making branches pointers to avoid unnecessary copying. So
22 yes, a branch is "commits reachable from a certain HEAD", but
23 conceptually this is the same as other branching models even though it
24 may not be implemented the same way.
25
26 > git is very difficult to learn, compared with, say Mercurial. To
27 > compare, if you do $ git help branch, you get a man page ~180 lines long
28 > dumped on you, and that's taking up the full width of my 240 character
29 > wide screen. If you do $ hg help branch, you get a 27 line concise
30 > summary, max. ~80 characters wide, which nonetheless is pretty much
31 > complete.
32 >
33 > git has become very popular (much as systemd has), possibly because
34 > programmers are frustrated at not being able to write in assembler any
35 > more. (At least, that's my theory). Like systemd, it has established a
36 > stranglehold on its domain. But severe disadvantages it most definitely
37 > has.
38 >
39
40 git is extremely popular, which could be a factor in its difficulty; I'm
41 guessing it's had a lot more development hours (and more obscure
42 features) put into it.
43
44 git is popular because it solved (and still solves) a problem
45 (distributed, parallel development) that at the time was not solved by
46 any other open source DVCS except Mercurial. Both projects started
47 around the same time, and I would imagine that having the Linux kernel
48 team backing git was a compelling reason to choose git over Mercurial.
49 Early on, iirc git was also faster since mercurial uses diffing, not
50 snapshots, and is written in Python.
51
52 I highly recommend Scott Chacon's "Pro Git": http://git-scm.com/book/en/v2
53
54 Alec
55
56 [1] http://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git