[deleted]
Moving from SVN to Git in 1,000 easy steps
11–20 of 70 posts
Re: Moving from SVN to Git in 1,000 easy steps
#12Speaking 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"…
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.
You can also freely branch and merge between your own private branches, without making everybody else see these numerous branches polluting the file hierarchy of the central repo.
More generally, I never liked how to cvs and subversion a branch is basically just a copy at the file level. That mixes version control metadata among the file paths that are themselves being version controlled.
Re: Moving from SVN to Git in 1,000 easy steps
#13Speaking 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"…
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, it's trivial just to create and use a new branch.
Ultimately, the reason you're not seeing much of an advantage to Git right now is because (from a user's standpoint) it's basically a superset of SVN. Once you get used to it and learn more about it, chances are you'll start improving your workflow to take advantage of more of its features. Git can basically support the same workflow as a centralized system, but it also supports other scheme.
Re: Moving from SVN to Git in 1,000 easy steps
#14Speaking 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"…
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…
Thanks for your comment, its the other schemes beyond a centralised workflow that I have not arrived at yet, as I'm new to Git and not finding it friendly so far (despite years of experience with other systems), I probably just don't get it yet ;-)
Re: Moving from SVN to Git in 1,000 easy steps
#15You 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.
Re: Moving from SVN to Git in 1,000 easy steps
#16Earlier 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.
You can also freely branch and merge between your own private branches, without making everybody else see these numerous branches polluting the file hierarchy of the central repo. More generally, I never liked how to cvs and subversion a branch is basically just a copy at the file level. That mixes version control metadata among the file paths that are themselves being version controlled.
THIS. I worked at an organization with ~700 branches with names all pretty much meaningless for a single project, when maybe 10 were actually being developed on. Makes it almost impossible to understand the repo.
Re: Moving from SVN to Git in 1,000 easy steps
#17Moral 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.
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.
Re: Moving from SVN to Git in 1,000 easy steps
#18Earlier 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.
> I could commit pretty freely using Subversion or Perforce to.
Pretty freely is not freely. That's like having 'decent' freedom of speech, y'see. Git allows you to commit any time, so fast you won't even notice the pause.
> 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.
Yes, it's faster because it only commits locally. You should not push every commit to the central repo, and you should be committing more or less every time you change a file. Git allows you to be far more granular than SVN or perforce did.
It also allows you to throw things away and try things out without worrying about hurting someone else. Branching in SVN/Perforce is simply not worth the effort, but on Git, it's trivial.
Re: Moving from SVN to Git in 1,000 easy steps
#19You 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 l…
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.
Re: Moving from SVN to Git in 1,000 easy steps
#20I 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.