

Why Git is Better Than X - schacon
http://whygitisbetterthanx.com

======
lowkey
I prefer Mercurial (Hg). I'm sure Git is the preferred choice amongst the
alpha of alpha geeks, but for small and medium-sized projects, Hg's simple
intuitive command structure, and more than adequate speed (2nd only to Git) is
a God send.

Git just seems overly complex for all but the most sophisticated workflows. I
could be wrong, but that has been my experience.

~~~
sh1mmer
This was my exact argument for Bazaar. After playing with Git 1.6 for a few
minutes today all my usual commands work.

It took me literally 3.5 minutes to get Git setup using the OSX install
package and fixing my .profile to include the new path. I'm very impressed.

Now if only Github had a trial membership with a Private repo...

~~~
bprater
I'm in agreement with Github having a free/trial private repo. It's a huge
oversight.

~~~
mojombo
GitHub is totally free and unrestricted for public code. This should give you
plenty of freedom to try out the service without paying. Also, as a promotion
for Cyber Monday, new signups today (12/1) can get a paid plan free for one
month.

~~~
tsally
Because of this, I just signed up to try it. I'm going to be honest though: I
wouldn't have without a private repository. I like to version control my
homework, and obviously it's against school policy to publicly post solutions
to homework. If this works out I'll end up paying for a micro plan, but I
never would have even given GitHub an opportunity without a private repo.

Of course, that's just my opinion. :-) You may not even be targeting students
anyway.

------
apu
The whole site would be more convincing if you included a section on reasons
why git is worse than X as well. I don't know git well enough to know these,
except for one: handling large binary files that change frequently.

It would make it seem more honest if you admitted that git wasn't the alpha
and the omega when it comes to version control. I think it would also show
people that you've carefully thought about this and are not just a 'fanboy'.

~~~
asjo
> I don't know git well enough to know these, except for one: handling large
> binary files that change frequently.

For the curious among us: what systems handle this better than git?

~~~
apu
Subversion is not terrible at this. It stores binary diffs.

~~~
pmjordan
Maybe they've improved this in recent versions, but I remember this being
excruciatingly slow.

------
axod
Why I don't care:

Because it simply doesn't matter that much IMHO. A startup doesn't succeed or
fail based on _which_ RCS it uses, it may fail if it doesn't use any at all,
and it may fail if people are wasting a large amount of time doing silly
things (Moving directories in cvs).

If you're hacking open source projects however, then I'd say Git is most
likely the way to go.

~~~
babo
I version control system determines the workflow so it has direct impact of
the internals of a company.

~~~
axod
For a small startup team, say 5 person max, is the workflow using git much
different than using svn say?

~~~
babo
We used it in a style where 2-3 people teams shared code to develop a feature,
a person often worked on different teams at the same time. When a group
finished they forwarded they changes to the 'merge master', a weekly shift of
lead developers of the company. After a code review the code reached our main
repository or landed back for a review. Sometimes weeks of development arrived
to the main tree in a safe way with full revision history. This kind of
development method was unheard before, the style change improved code quality
and reduced conflicts.

My favorite story when we worked with a college thousands of kilometers away
till the last minute to demonstrate a key feature to a customer at a trade
show, exchanging revisions by emails, delivered on a USB stick. That's a real
technology start-up way to handle development. I wrote and debug a lot of code
to that company but my biggest impact was to introduce mercurial to the team.

------
justindz
I've used svn and git a little and am shopping around for something to use on
a current project. I found git harder to use than svn, given that I'm not a
power user. I noted that the last item on the page seems to reflect that--git
is only easier to learn than perforce, according to the site.

Is that really true? I might just be dumb, but I had a harder time with git.
Given that I'm in mostly single-user mode, it seems like I might be more
productive with svn simply because I wouldn't have to wrestle with it as much
to get going.

Can anyone recommend a "git for people who can understand and operate svn
without hurting themselves?" guide? Or is the value of git significantly
lessened in single-user mode?

~~~
gcv
If you really just want a minimal source control system, Git does the trick
well enough. I don't think you need anything more than 'git init' (make a
fresh project), 'git commit -a' (commit all new changes except for deleted or
renamed files), 'git add' (to add new files), 'git rm' (to remove files), 'git
checkout' (for reverting changes), 'git log' (obvious), and 'git diff' (also
hopefully obvious). Put a .gitignore file in the root of your project listing
globbed filenames for everything you don't want to manage. Run 'git commit'
after every sequence of 'git add' or 'git rm' invocations. That's it. You
shouldn't need any more documentation than this paragraph.

Branching is a killer feature, as is clean history management, as is the
index, and when you find yourself wishing more control over what happens to
your source code, wishing for freedom to experiment, all these tools will be
there waiting for you.

~~~
nostrademons
'git mv' for moving files, and I'm overly dependent upon 'git status' for
checking what's changed.

~~~
jrockway
mv is just sugar, though, you can easily copy the file using unix "cp" and
delete/add to get the same result. Git does not track renames.

~~~
etal
Or, just use the Unix mv, and let Git figure out what you did at the next "git
add .".

------
vorador
Another weekly post about why git's better that anything else. It's just the
fourth in four weeks.

------
almost
I wish I could use Git on one of my current projects. But I need to work with
non-programmers (on OSX in my case) and any command line stuff (or anything
more complicated than checkout/add/update/commit) is totally out of the
question.

Still, I'm sure it won't be long...

~~~
speek
I also work in an environment with people who should not be going near their
command line. Well, its not that they shouldn't but they don't want to be
forced to learn commands.

I'm working on a Git GUI that should be fairly beautiful (I'm a former graphic
designer), but there aren't really any good GUIs out there right now.

If you do decide to use some sort of VCS, svn has some great GUIs.

like Versions (<http://www.versionsapp.com/>), Cornerstone
(<http://www.zennaware.com/cornerstone/>) or ZigVersion
(<http://zigversion.com/>).

Versions is nice because it can easily integrate with their hosted subversion
stuff called Beanstalk.

~~~
brunoqc
For Mercurial, there is TortoiseHg:

<http://tortoisehg.sourceforge.net/>

~~~
silentbicycle
Which works very well on Windows, FWIW.

------
cl-user
I am more of a bzr and svn user. Both work quite nicely for me. I haven't
really used git on a project.

I know git performance is much much better than bzr but as thats not a major
concern for small/medium projects, could someone who has used both bzr and git
give some pointers on what one would be nicer to use than the other in areas
other than performance?

~~~
etal
From what I've seen of bzr and git, if you're competent with one, learning the
other won't change your life the way a switch from cvs to bzr might. The way
git figures out what you've done to a directory tree using sha1 hashes is
interesting; incidentally it won't automatically add an empty directory. In
bzr, you tell the VCS what you're doing so it can track operations better; git
generally doesn't care about anything but the contents of the files in your
tree. The staging area and in-place branching in git are pretty cool, but not
essential, and I suspect they'll be picked up by bzr and hg in due course.

Mark Shuttleworth wrote a series in his blog about what he cares about in
version control, and why he picked bzr for Ubuntu and Launchpad, which is an
interesting counterpoint to the git lovefest we've been seeing here.

------
schacon
by the way, as a nice demonstration of some of this git/github greatness,
there have been a number of useful changes submitted by users that have been
pulled in and deployed now, including the beginnings of a french translation
of the site that I've put up at <http://fr.whygitisbetterthanx.com>

you can see the network activity here :
<http://github.com/schacon/whygitisbetter/network> \- all of which has
happened since I posted this news item 2 hours ago.

------
halo
It's a funny coincidence this turns up when I spent about 30 minutes trying
and failing to get Git working with Github earlier. I'm not sure if it was the
flaky Windows port or not, but it just wasn't happening.

------
brunoqc
Git seem nice, but as far as I know Github only use ssh. It suck when you are
at work or school.

~~~
ptman
How is supporting only SSH bad? SSH is (or really should be) allowed through
all firewalls. git:// support would be much harder to get accepted.

------
newt0311
Inaccurate. For example, in the section for "Any Workflow," the author
contends that git is better than bzr, hg, svn, and perforce. However, this is
completely false. bzr has far better support for the central repository (svn-
style workflow) with its linking of repositories and hg and bzr both have
excellent support for the models that Git supports. Funny that the site tries
to defend against fanboyism while it itself is a poster boy for it.

~~~
wmf
The "Any Workflow" section is a little confusing. The fine print says "[Other
SCMs] can do the simple flows I've described above, but they cannot do them
with multiple simultaneous local branches." I don't understand this well
enough to be convinced, and it's hardly good form to use examples that don't
demonstrate your point.

~~~
schacon
You make a good point, so I have removed the dscm tags from that one. I added
this because I feel that the ability to keep full branches in the same
repository that you can push and delete easily gives you far greater
flexibility than bzr or hg, which you can only get the exact same
functionality by having separate repositories that are clones of each other.
However, since that's not what I was demonstrating in that section and it's a
bit too complicated to amend easily, I've removed it and focused in that
section on the advantages over svn and perforce. perhaps later...

~~~
newt0311
I should point out that hg is perfectly capable of maintaining multiple named
branches in the same physical repository. Checkout hg branch. I am not that
familiar with bzr but it probably has something similar.

