Moving from SVN to Git in 1,000 easy steps • Hacker News Board

Re: Moving from SVN to Git in 1,000 easy steps

#51

Post by JoshTriplett » Sat, Dec 03, 2011, 2:31 AM UTC

nupark2 wrote: post #46

JoshTriplett wrote: post #38

Earlier quoted context omitted.

> [1] My current employer uses SVN and I was told, in no uncertain terms, "The use of Git is a fireable offense." The lead developer really hates Git. Reminds a bit of this quote in LWN from David Woodhouse (a Linux kernel developer at Intel): 'If my corporate overlords told me I had to use my Exchange "messaging" account for external email communication, they would get a quite clear 'no' in response. My response may…

> More seriously, it sounds like someone who had a bad experience with Git at one point got put in an undeserved position of power in which they got to enforce the results of that bad experience on everyone else. I set technical direction and while using git isn't a firable offense, we will never support it as the official SCM system. The reason is quite simple: in a centralized environment, it increases costs and co…

There's a big difference between "not the official SCM system" and "a fireable offence". As a developer, I frequently use a pile of tools that don't have official support, because they help me get my job done more effectively than the "official" tools. Sometimes those end up becoming the official tools later, sometimes they don't.

But in any case, some of the issues you've listed represent bugs in development processes, not in Git.

> - People hiding their work in local branches where none of the other engineers can follow along.

Good developers using Git don't "hide their work" in local branches any more than they "hide their work" in an editor before they save it; sometimes you just have work in progress that shouldn't get pushed yet. (I certainly hope you have policies about when to commit, which include things like "the code compiles" or "passes tests" or "smells right"; if so, why aren't you concerned about people "hiding their work" in their uncommitted working copies?) If that work in progress has a sufficiently large scope that it needs more developers involved, then the branch may want to live in a repository accessible to others.

Before I had git-svn, when I had to work with SVN repositories, I ended up having several local copies of the repository, and doing the "small self-contained commits" thing manually by copying bits into and out of working copies. Git provided much more structure to that process, as well as making it faster and more efficient.

> - Getting massive rebased commits once every day (or worse yet, every few days).

Don't do that. You can and should push arbitrarily often.

> - An open-source Linux-inspired development model consisting of a massively distributed ecosystem of competing/disparate/intertwined branches.

If you have a project anywhere near as large as the Linux kernel, you'd be lucky to end up that well organized and optimized. But while you still have a team that can regularly communicate with each other on a list low-volume enough for people to read all the mails, you don't really need that ecosystem of hierarchical branches and repositories; nonetheless, you can get a lot of value out of Git even when using it with a single central repository.

Re: Moving from SVN to Git in 1,000 easy steps

#52

Post by chucklarge » Sat, Dec 03, 2011, 2:35 AM UTC

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.

Re: Moving from SVN to Git in 1,000 easy steps

#53

Post by xpaulbettsx » Sat, Dec 03, 2011, 2:38 AM UTC

jcheng wrote: post #27

cynicalkane wrote: post #19

Earlier quoted context omitted.

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 u…

> on a directory-tree data structure Or on a directed acyclic graph of refs; that's the definition that made everything click for me.

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... is absolutely worth your time if the above statement didn't trigger a lightbulb in your head

Re: Moving from SVN to Git in 1,000 easy steps

#54

Post by brown9-2 » Sat, Dec 03, 2011, 2:39 AM UTC

j_col wrote: post #9

jlongster wrote: post #6

Earlier quoted context omitted.

It's saving you because you can freely commit without ever running into a conflict suprisingly. Deal with the merges and conflicts when you want to. Also, it's lot faster to commit. You shouldn't be pushing out every commit -- just commit a lot and when you want others to see it, push it.

I could commit pretty freely using Subversion or Perforce to. As for the faster Git commits, is that just because you are only commiting locally? You still have the overhead of pushing to your central repo. Reading the original article, it seems his reason for switching to Git can be summed up in one word: Github.

But in svn or p4 those commits are visible to everyone else immediately. With git they are only visible when you are ready to make them so - and you can amend or merge them into a single commit or slice them however you want beforehand.

Having your own private repo other than what is on the server allows you to experiment and make a lot more mistake without affecting others.

Re: Moving from SVN to Git in 1,000 easy steps

#55

Post by aeontech » Sat, Dec 03, 2011, 2:56 AM UTC

nupark2 wrote: post #46

JoshTriplett wrote: post #38

Earlier quoted context omitted.

> [1] My current employer uses SVN and I was told, in no uncertain terms, "The use of Git is a fireable offense." The lead developer really hates Git. Reminds a bit of this quote in LWN from David Woodhouse (a Linux kernel developer at Intel): 'If my corporate overlords told me I had to use my Exchange "messaging" account for external email communication, they would get a quite clear 'no' in response. My response may…

> More seriously, it sounds like someone who had a bad experience with Git at one point got put in an undeserved position of power in which they got to enforce the results of that bad experience on everyone else. I set technical direction and while using git isn't a firable offense, we will never support it as the official SCM system. The reason is quite simple: in a centralized environment, it increases costs and co…

> "... provides no value to offset that."

That right there, tells me that you have never actually used git in a team environment with a good workflow enough to actually learn about its advantages and disadvantages. Sure, git is not perfect, but to boldly say that it offers no value in a centralized environment is, ah, how shall I say it... self-assured to the point of trollishness.

I, and many many other people have used git for years, both in centralized environments and not, and I can tell you that git (and more broadly, any decentralized VCS) has tons of useful features in a centralized environment compared to SVN/CVS and their ilk. Just off the top of my head, features I could not live without now:

- much more powerful branch merge tracking

- much better conflict resolution compared to CVS/SVN.

- partial commits

- history rewriting (massively useful in cleaning up before pushing) - ability to work without network connection

- ability to cherry pick commits between branches

The problems you described are failures of workflow due to bad process and/or bad developer education, _not_ failures inherent in the design of any given distributed VCS. I have never had to deal with any of those issues, because we have always ensured that we have a good workflow in place.

Re: Moving from SVN to Git in 1,000 easy steps

#56

Post by aneth » Sat, Dec 03, 2011, 5:26 AM UTC

j_col wrote: post #5

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"…

While I'm sure others can address all of the many advantages of git, it's one of those things you don't realize how much you "need" it until you have it, then you take its power for granted until you are stuck using svn. Think iPad, running water, the wheel, a spreadsheet application, or any variety of things.

Re: Moving from SVN to Git in 1,000 easy steps

#57

Post by [deleted] » Sat, Dec 03, 2011, 7:56 AM UTC

nupark2 wrote: post #43

tikhonj wrote: post #13

Earlier quoted context omitted.

For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day. Another benefit I've found--as a student with an internet connection that isn't always on--is that I can still commit without it. It's also much easier to use branches in Git. If I want to try something weird, or temporarily break some code, i…

> For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day. This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs. Worse yet, sometimes people use rebase to hide the intermediate commits and you ge…

[deleted]

Re: Moving from SVN to Git in 1,000 easy steps

#58

Post by Tobu » Sat, Dec 03, 2011, 8:21 AM UTC

jinushaun wrote: post #20

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 not…

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}

Re: Moving from SVN to Git in 1,000 easy steps

#59

Post by Tobu » Sat, Dec 03, 2011, 8:29 AM UTC

oinksoft wrote: post #50

whalesalad wrote: post #3

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.

Hm, I've run many a 5000+ revision subversion repository through git-svn and had no issues. I'm not a git evangelist, but the tools for migrating from subversion are pretty good.

My usual way of interacting with any svn repository is to run the entire history through git-svn, a command which takes all of five seconds to issue. There are a few extra niceties to consider when the switch is permanent, like setting up an AUTHORS identity map for the import and maybe gathering public keys for a gitolite, but the tooling side is entirely painless.

Re: Moving from SVN to Git in 1,000 easy steps

#60

Post by chousuke » Sat, Dec 03, 2011, 9:30 AM UTC

nupark2 wrote: post #43

tikhonj wrote: post #13

Earlier quoted context omitted.

For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day. Another benefit I've found--as a student with an internet connection that isn't always on--is that I can still commit without it. It's also much easier to use branches in Git. If I want to try something weird, or temporarily break some code, i…

> For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day. This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs. Worse yet, sometimes people use rebase to hide the intermediate commits and you ge…

> This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs.

Git is decentralised. If you think you might get conflicts with some other developer, just ask them to push their branch somewhere public where you can fetch their work and look at what they're doing. Or they can export their commits as a tarball and bring it to you on a USB drive if you have no network connectivity for some reason. :P

> Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit.

To be honest, this still sounds like a workflow problem. if "Implemented X" is too huge to be a single commit, then the person who pushed it was lazy and didn't bother to spend enough time to make good commits. If it really only "implements X", then even if it is big, it's at least self-contained.

You should spend time thinking about what you commit. It's not just a matter of getting your code somewhere safe; the code in your working directory is the raw material from which you create a new snapshot of the project that represents an improvement. This is really difficult to do with SVN, but it should be your default workflow in git. It's more work beforehand, but it improves code maintainability and makes bisecting more effective.

It's likely that most developers are not disciplined enough to do this for every commit while they're coding. Fortunately, rebasing allows you to defer all that work to just before you push. Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project.

How the development actually happened is completely uninteresting in git. Ideally the log is a history of patches applied to the project, each of which changes only one thing, and is complete by itself (later commits can depend on earlier ones, but the reverse should not be true)