
Moving from SVN to Git in 1,000 easy steps - gavingmiller
http://codeascraft.etsy.com/2011/12/02/moving-from-svn-to-git-in-1000-easy-steps/
======
jtchang
You guys laugh but migrating version control systems can be one of the most
nightmarish projects an organization chooses to undertake. It's right
alongside rewriting mainframe software (that probably has been working for 20
years) and an overhaul of the employee HR systems.

It's scary. It's fraught with pitfalls. But in the end everyone hopes the
result is a better tool.

We need more of these writeups. I personally love git. I just think the
learning curve is steep. Think you know git? Next day someone teaches you some
fancy new command you didn't even know existed.

I think git is really taught wrong in a lot of tutorials. They never focus on
_workflow_ and determining what works for you and your team (if you have one).
Once you decide on the workflow all the git commands you need become apparent.

~~~
cynicalkane
It's best to think of Git not as a version control framework but as a library
of functions on a directory-tree data structure (edit: with a history). With
this mental model, you realize that

1) there's all kinds of crazy things you can do

2) for a given crazy thing someone's probably already done it, and if it's not
too far-out there's probably a command for it.

The reflog makes uncollected garbage available to the user, meaning that if
you screw up you can just roll back to an old commit, carrying with it an
entire history, even if that commit is no longer referenced by the repo.

~~~
jcheng
> on a directory-tree data structure

Or on a directed acyclic graph of refs; that's the definition that made
everything click for me.

~~~
xpaulbettsx
The key that makes things click for me is, the Commit is the most important
'unit' of Git. Tags, branches, pseudo-refs like HEAD are all just mutable or
immutable (like tags) _pointers_ to _commits_.

[http://tom.preston-werner.com/2009/05/19/the-git-
parable.htm...](http://tom.preston-werner.com/2009/05/19/the-git-parable.html)
is absolutely worth your time if the above statement didn't trigger a
lightbulb in your head

~~~
gwern
What is this, a discussion of Haskell monad tutorials? :)

------
j_col
Speaking as a long-term Subversion and Perforce user, I'm finding the switch
to Git (forced on me by a job change) painful. My old work flow:

1\. Commit my code to the central repo.

My new and "improved" Git workflow:

1\. Commit my code to my local branch. 2\. Push my local branch to the central
repo.

As we're using Git as a centralised source control anyway, what is this extra
work saving me over using a "traditional" centralised source control? In other
words, what's the point in using a decentralised source control system in a
centralised manner, and how many teams are truly using Git in a decentralised
manner?

~~~
pkaler
You may be doing it "wrong".

My old Perforce workflow: code, code, code, code, code, code, code, code,
commit

My new Git workflow: code, commit, code, commit, code, commit, code, commit,
code, commit, code, commit, push

It's the difference between single-piece flow and large-batch production in
Lean Manufacturing.

~~~
jinushaun
This, and branches. I rarely used branches in svn, but I branch all the time
in git locally.

If you try to use git like svn, it's pretty frustrating. Seems like a lot of
work for no gain. But if you embrace the git philosophy of commit early and
often and local feature branches, you'll understand how git got so popular.

In svn, I often run into the situation where I'm working on a new feature,
want to save what I've done (because it works), but it's not ready to check
into the central repo. Then I usually do something that breaks the whole thing
locally, but I have no way of undoing that change since nothing has been
committed yet. I've seen svn users copy and paste entire directories just to
"snapshot" their work. With git and local commits, you don't have this
problem. You "save" your progress as you go along by committing it locally and
when something breaks, you revert locally. Then when your feature is ready,
you push the whole thing to the central repo.

------
chucklarge
I'm an engineer at Etsy and went through this transition. I am certainly no
expert on either svn or git. To mirror closely how i used svn means i need to
run a couple more git commands per push, a little annoying but no big deal.

I think the real pain comes when there are problems. How do i unfuck what i
just did?. You're getting stressed out, there are people waiting on you to get
your commits in. I had my flow down with svn, but now what do i do? Compound
that with 100 engineers experiencing that on some level as we transitioned, it
was trying.

It's true of changing any tool or workflow, though. You rely on muscle memory
or run on auto-pilot and suddenly you don't know what to expect from your day.

------
jinushaun
I have to agree with the article. GitHub's git tutorial is a lot more useful
and easier to follow than the other git articles I found online.

My only complaint about learning git is the lack of distinction between what
is a keyword and what isn't. The command line syntax is chock full of words.
In particular, "upstream" was the most confusing thing for me starting out.
Only much later did I realise that there was nothing special about "upstream".
It's just an arbitrary name for a remote repo, but you wouldn't know that as a
newbie reading these tutorials. It is only by convention that upstream has a
special meaning.

~~~
Tobu
Actually, @{upstream} has a special meaning, and is a refname for the current
branch's upstream. For example:

    
    
      # commits that are on the current branch but not upstream
      git log @{upstream}..
      # commits that are upstream but not on the current branch
      git log ..@{upstream}
      # the commit path between the current branch and upstream
      # (all commits are exclusive to either branch)
      git log ...@{upstream}

------
v21
It's really excellent to read a guide on this kind of thing that focuses on
the difficult human factors rather than the easier technical ones.

------
jarjoura
We had an entire orgs source-code in one SVN repository. It was useful for
moving files from one project to the next to keep history and enabled anyone
in the org to easily commit to any project.

Obviously that wasn't scalable. (My inbox of commit log emails was insane.) So
we transitioned to git. Plus, most of the engineers were already using git-
svn. It just took someone who had a free weekend to "git svn clone" and move
everyone over to that.

It was PAINFUL at first. I was one of the grumpy people, but after I got the
hang of git, I am so glad we just ripped the bandaid off.

------
whalesalad
Moral of the story: If you're on SVN right now, abandon it as soon as
possible. Moving even a 2000 commit repo is no fun, especially when there are
more developers involved.

~~~
jordan0day
That wasn't the moral of the story at all!

"If you can deal with your current source code system, do not go through this
pain. Seriously. This was a long, painful process for us. Over the years, many
tools, systems, and processes had become deeply intertwined with our
subversion installation. That said, if your team is small, or your source
control system isn’t tied into anything, go for it! Just do it as soon as
possible – the only time better than today was yesterday."

The first half of that paragraph basically says that it very well might be
more painful to switch to git than it is to keep using your existing system.

~~~
JoshTriplett
It also says, though, that if you want to switch, switch now, not later.

