4 ms·

Honestly, it's a lot easier than SVN if you're doing anything even moderately complicated. I think there's a bias from people who learned SVN first.

eli 13y ago
I dunno, SVN has had great integration with the Windows Explorer, at least when I learned it a decade ago. It really was pretty intuitive. (Now, granted, SVN had many other imperfections, but it worked pretty well for smallish teams.)
- nine_k 13y ago
  Git has troubles under Windows. If you want a simple dvcs, use Mercurial. It's well supported.
matwood 13y ago
Exactly. The first thing I tell people when moving over to git is to forget SVN ever existed. Thinking in terms of SVN (or another non-Dvcs) is what I find trips people up over and over again in git. This isn't to say the git cli is perfect, but once a person understands how a DVCS works the typical git use case is easy. And then when someone needs an advance feature they can look it up. Git continues to surprise me with its code wrangling abilities.
- sopooneo 13y ago
  It's funny, when I was learning Git, it was the first source control system I'd ever used, but most of the tutorials were for people switching. So all the (justified) emphasis to forget all I know about VCSs was just baffling for me. And with no baggage, the basic mechanics seemed perfectly sensible.
- teacup50 13y ago
  > Git continues to surprise me with its code wrangling abilities. That's not a good thing. Perhaps it's not that people are "tripped up" by thinking in terms of SVN, but rather, are frustrated that things that should be simple aren't. Instead, you want them to adopt an anything-goes git model where nearly everything is mutable, no data is sacred, branches and tags can be dropped at will and be gone from the repo refs, and people run around rewriting history willy nilly because they can. Meanwhile, the poor SVN user wonders why they couldn't just commit, update, and get back to coding already.
  - matwood 13y ago
    Actually it is a great thing. I'm not even sure SVN could do what I often have to do. I have 2 large projects that diverged into different projects awhile back. They each share some code and often bugs need to be fixed in both. With git I can add each project as a remote to the other and cherry pick commits back and forth to keep both projects up to date without much fuss. Thinking about what should be simple and isn't is branching in SVN. Most people know very little about branching because SVN makes it so hard to use. I would argue that people switching to git are not having a hard time with git so much as they are finally learning proper source control techniques in addition to git. The basics in git are simple though. If a person is just replicating SVN, git adds 2 more steps (stage and push). Like I mentioned above though, people are not just learning git, they are also finally learning proper SCM.
  - click170 13y ago
    You have a point regarding things that should be simple, not being simple. I'll agree that can be a problem. What I don't agree with is the idea that you have to use all the advanced features. Your last line hits on the idea that SVN users can't just commit, update, and get back to coding. Can't they? Can they not simply ignore everything extra until they hit a problem that the tools they've decided to use can't solve on their own? Branching, bisecting, rebasing et al are not required in a git-centered workflow, they just make it easier to do Black Magic (tm).
- Ygg2 13y ago
  > Thinking in terms of SVN (or another non-Dvcs) is what I find trips people up over and over again in git. No, thinking in terms of non-Git is what trips people over. I came from Hg and still had to struggle with Git, because it's CLI is a mess and it's system behind is rather weird. Plus things like Rebase and Cherry Pick did't exist in Hg (not by default and not three years ago). Lots of it's underlying model still leaks when using, that having good knowledge of it is mandatory.
sixothree 13y ago
Not if you're a project manager.

eli 13y ago

I dunno, SVN has had great integration with the Windows Explorer, at least when I learned it a decade ago. It really was pretty intuitive. (Now, granted, SVN had many other imperfections, but it worked pretty well for smallish teams.)

nine_k 13y ago
Git has troubles under Windows. If you want a simple dvcs, use Mercurial. It's well supported.

matwood 13y ago

Exactly. The first thing I tell people when moving over to git is to forget SVN ever existed. Thinking in terms of SVN (or another non-Dvcs) is what I find trips people up over and over again in git. This isn't to say the git cli is perfect, but once a person understands how a DVCS works the typical git use case is easy. And then when someone needs an advance feature they can look it up. Git continues to surprise me with its code wrangling abilities.

sopooneo 13y ago
It's funny, when I was learning Git, it was the first source control system I'd ever used, but most of the tutorials were for people switching. So all the (justified) emphasis to forget all I know about VCSs was just baffling for me. And with no baggage, the basic mechanics seemed perfectly sensible.
teacup50 13y ago
> Git continues to surprise me with its code wrangling abilities. That's not a good thing. Perhaps it's not that people are "tripped up" by thinking in terms of SVN, but rather, are frustrated that things that should be simple aren't. Instead, you want them to adopt an anything-goes git model where nearly everything is mutable, no data is sacred, branches and tags can be dropped at will and be gone from the repo refs, and people run around rewriting history willy nilly because they can. Meanwhile, the poor SVN user wonders why they couldn't just commit, update, and get back to coding already.
- matwood 13y ago
  Actually it is a great thing. I'm not even sure SVN could do what I often have to do. I have 2 large projects that diverged into different projects awhile back. They each share some code and often bugs need to be fixed in both. With git I can add each project as a remote to the other and cherry pick commits back and forth to keep both projects up to date without much fuss. Thinking about what should be simple and isn't is branching in SVN. Most people know very little about branching because SVN makes it so hard to use. I would argue that people switching to git are not having a hard time with git so much as they are finally learning proper source control techniques in addition to git. The basics in git are simple though. If a person is just replicating SVN, git adds 2 more steps (stage and push). Like I mentioned above though, people are not just learning git, they are also finally learning proper SCM.
- click170 13y ago
  You have a point regarding things that should be simple, not being simple. I'll agree that can be a problem. What I don't agree with is the idea that you have to use all the advanced features. Your last line hits on the idea that SVN users can't just commit, update, and get back to coding. Can't they? Can they not simply ignore everything extra until they hit a problem that the tools they've decided to use can't solve on their own? Branching, bisecting, rebasing et al are not required in a git-centered workflow, they just make it easier to do Black Magic (tm).
Ygg2 13y ago
> Thinking in terms of SVN (or another non-Dvcs) is what I find trips people up over and over again in git. No, thinking in terms of non-Git is what trips people over. I came from Hg and still had to struggle with Git, because it's CLI is a mess and it's system behind is rather weird. Plus things like Rebase and Cherry Pick did't exist in Hg (not by default and not three years ago). Lots of it's underlying model still leaks when using, that having good knowledge of it is mandatory.

sixothree 13y ago

Not if you're a project manager.