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 |