

3 reasons to switch to git - jwilliams
http://markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/

======
artificer
Each version control model has it's own merits and drawbacks, and there will
always be situations where one is good and another isn't. For example, while
many OSS projects have switched to distributed vc's such as git and mercurial,
two of the largest oss projects still remain loyal to Subversion, FreeBSD and
KDE. If you search their mailing list archives, you will see that after long
thought, both projects decided that the Subversion model reflects better their
development style. So, no, git is not simply "better" than subversion, it just
reflects a different development methodology.

~~~
albertcardona
The nice part is that with git, one can interact with svn projects seamlessly
via git-svn -- so endless local commits may be repacked to one single remote
commit or push.

But svn lacks suh flexibility to interact with others. Hence git > svn, as in
_svn is a tiny subset of git_.

~~~
artificer
It's not so simple. For example, if I remember correctly,git lacks a way to
checkout and work on a small subset of a development tree, as it tracks whole
trees at a time. This feature is something that svn and cvs offered long ago.
To do that with git you have to break the tree into small sub-trees, as the
X.org guys have done. This may be considered as a drawback for some people.

For more information on why git was not chosen instead of svn for FreeBSD you
can look at <http://wiki.freebsd.org/VCSWhy>

Again, each vc has it's uses, and nothing is merely a 'subset' of another.

------
pmjordan
I'll add a fourth, which is the "killer feature" for me and my current
workflow:

Git allows working from more than one system at once without requiring a
constant server connection. When I'm on the go and want to make changes to my
code from my laptop, I can make commits, I've got access to the full history,
etc. All that's required is a pull from my desktop before I leave my office,
and I've got a shell script that pulls the repositories for all my projects at
once.

With something like SVN, this kind of thing was a major pain, as I'd either
have to work just with my local copy on the laptop (leading to poorly tracked
mega-commits), or copy the whole file system structure of the repository to
the laptop, which quickly gets you into desynchronised territory. Add another
developer and you're instantly dead with that kind of system.

~~~
thomasmallen
Mercurial provides the same "killer feature", which I think nullifies any
"killer feature" status for git (implies exclusivity, I believe).

~~~
pmjordan
Fine. Call it the killer feature of distributed version control systems. Works
for me, in any case.

~~~
thomasmallen
Why do you prefer Git to Mercurial? I've only used Mercurial.

~~~
pmjordan
I'm not an expert in git (still learning) and I've hardly used Mercurial at
all, so right now there's no particular reason. There are probably better
people to ask that question. :) I'll try hg in a project sooner or later, but
learning to get to grips with 2 version control systems at once while trying
to do something productive seemed a bit much. There wasn't really anything on
the feature lists that tipped the scales; the Linus Torvalds association and
the resulting curiosity probably did.

I can't believe I fell for a celebrity endorsement. ;)

~~~
thomasmallen
I prefer Mercurial for mostly cosmetic reasons (I believe that Git and
Mercurial are very close, feature-wise). I prefer having one command "hg" ("hd
add", "hg serve", etc.) to the dozens of commands for git. I think it has more
to do with the way that I think than anything else: Mercurial commands are
easier to remember for me.

~~~
pmjordan
Um, "git add", "git push", etc. work fine. I think the hyphenated versions are
deprecated anyway.

------
markessien
I sometimes feel like the technology world is similar to the fashion industry
- this year CVS is, then it's suddenly SVN, and when I make the switch,
everyone is using GIT, and I'm sooo last year with my SVN.

I'll wait out the GIT wave. If it's more dominant than SVN in 2011, that's
when I'll switch.

~~~
mechanical_fish
As others have mentioned already in this thread, the git-svn bridge works very
well. You can adopt git and get a bunch of its features (local repository
mirrors and multiple local branches) while still working atop your SVN
repository. You give up some things (you can't really do cross-repository
merges with git-svn -- when you want to communicate with your peers you have
to do it via the SVN repo) but it is still great. It's not worth waiting
another five years for the extra features. ;)

I've found that the CVS-to-git workflow is a bit more annoying. You can import
CVS repos into git, but you can't really push anything back without using
patches.

------
bradgessler
When you delete the master branch, you are enlightened.

~~~
silentbicycle
Explain.

~~~
astine
The concept of a primary working tree is a relic of non-distributed VCS? I
could see working with several branches or versions of a project but not
having any single canonical version. I've never done it, but I could see
working that way.

~~~
bradgessler
Exactly.

On our project we deleted the master branch in favor of having two branches we
work off of: production and development.

The production branch reflects what is in production while development
contains new completed features that each developer builds in all of their own
branches.

------
axod
"You’d like to work on each of your 4 features A, B, C, and D independently
and somewhat in parallel, though B looks like a quick win."

Does anyone here seriously work like that?

Seems like git has some advantages if you branch a lot, but I don't think
branching too much is particularly healthy. I can see why it's good for open
source if you have a ton of contributers, but what's the win for a small team
who hardly ever branch?

~~~
mojombo
I do this all the time on the GitHub repo itself. I'll have an idea for a
small tangential feature (like per-repo pageview stats) that I want to spend
an hour hacking on to see if it goes anywhere. By branching off master, I can
experiment to my heart's content and then just shelve the feature easily if I
don't finish it. Then later on, getting it back is just a single command away.
Git really is a hacker's best friend. It facilitates exploration and
experimentation of code. Fits perfectly with a startup mentality.

~~~
timr
You can branch and merge easily with SVN, too. What does Git add, other than
the ability to do it locally?

~~~
pjhyett
"You can branch and merge easily with SVN, too."

That's the nicest thing I've heard anyone say about SVN ever.

------
dzorz
An appeal to authority argument: newly released Android code is kept in git
repository. Google built a new wrapper around git called "repo".

------
sfamiliar
seems like git isn't designed to handle long-running branches, or branches
with more than one committer. i'm still pretty novice at git, and was hoping
this article could clear that up, but mailing patches around seems ..
inefficient.

anyone want to correct me? i like git in most respects, and am now using it on
a few projects.

~~~
orib
Hm? Why would you think that?

Did you realize that your master/ branch is just one such long-running branch,
and one that's not special in any way other than being the default for some
commands...

As far as multiple committers on one branch -- well, you can do it, but with
'git rebase' and friends, it's just easier to do your own work on a short
lived branch off your primary branch, and just merge in stuff as you get it
done.

It's not that git makes it difficult to do it compared to other version
control systems; it's just that it's a nicer workflow if you use short-lived
topic branches to do development because you don't to worry about what other
people are doing until you decide you want to take a look at it and merge it
in. The short-lived private branch + lots of merges workflow is just easier
because it prevents interruptions in your workflow.

As far as emailing patches, it's a matter of taste. It's certainly easier to
make sure all changes get reviewed if patches are mailed around, because
people tend to read their mails. Personally, I just use a post-update hook to
mail out a list of changes for each commit, and review them later, since it's
always relatively easy to back out or fix a patch -- after all, it is a
version control system.

------
swombat
Only one reason needed:

git > svn

