Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from SVN to Git in 1,000 easy steps

codeascraft.etsy.com

Post reply on HN
Print view View original

61–70 of 70 posts

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

#61

Post by sjwright »

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…

> I don't really understand why git users keep repeating this trope.

You can create a branch in Git without having to touch the main repository. It's a lot cheaper mentally to create a local branch than a globally viewable one. In particular, it's a lot cheaper to create a branch when you don't have to think about whether the work is important enough to deserve one, or if your crazy idea might end up being an embarrassing failure. When a decision only affects yourself, it's a lot easier to be bold.

> SVN has merge tracking, so it Just Works:

SVN can branch easily, and it remembers how a merge went down, but it doesn't know how to merge a branch back into the truck when the truck has since progressed. When SVN merges, it doesn't know if a difference between the two branches is because it was changed on the trunk or on the branch. It just sees a difference.

Git can replay the changes made in the branch on the updated trunk, or vice versa.

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

#62

Post by ConstantineXVI »

jtchang wrote: post #15

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

We (10-person startup) actually migrated from TFS to Git a few months ago. The technical migration was mostly smooth (found a TFS->Git export tool); like many other people, the main issue's been the DVCS culture shock. I was "lucky" to come on right as we were beginning the migration (which I ended up leading by default), so I haven't had all of the TFSisms to work out of my system that everyone else did.

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

#63

Post by nupark2 »

aeontech wrote: post #55
nupark2 wrote: post #46

Earlier quoted context omitted.

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

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.

Most of the features you're discussing encourage that workflow/bad process/bad developer behavior, because they were built entirely to support Linux's development methodology in which that behavior isn't not considered a hindrance.

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

#64

Post by jeltz »

nupark2 wrote: post #44
jeltz wrote: post #31

Earlier quoted context omitted.

Additionally for working with multiple fixes at the same time git stash -p, git add -p and friends are great tools. I sometimes see a bug when either fixing another bug or implementing a feature. And if that bug is trivial (i.e. it would take less work to fix it right away compared to remembering it) I can fix it right away, and commit it later in a new branch unrelated to the one I was actually working on. With svn…

> With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember. svn diff >patch-saved-changes svn revert -R . (work work work) svn patch

I used that all the time when coding with svn, and while not as handy has git stash it is workable.

But what I was specifically referring to is the -p flags of various git commands (stash, reset, add, checkout, ...) so you can interactively only stash away what you wish instead of the entire working directory (or an entire subdirectory of it).

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

#65

Post by [deleted] »

nupark2 wrote: post #44
jeltz wrote: post #31

Earlier quoted context omitted.

Additionally for working with multiple fixes at the same time git stash -p, git add -p and friends are great tools. I sometimes see a bug when either fixing another bug or implementing a feature. And if that bug is trivial (i.e. it would take less work to fix it right away compared to remembering it) I can fix it right away, and commit it later in a new branch unrelated to the one I was actually working on. With svn…

> With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember. svn diff >patch-saved-changes svn revert -R . (work work work) svn patch

[deleted]

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

#66

Post by eropple »

chousuke wrote: post #60
nupark2 wrote: post #43

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

> 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.

Disagree, because the commits are merged in and I can clearly walk through them. You should think very carefully about what you're committing and when--but that doesn't make rebase a license to do stupid things to make life harder for other developers, and personally I am completely and entire convinced that that's really all rebase does; I consider it one of the biggest brain damages of git and in pushing the SVN->git migration crusade (because even with rebase stupidity it's vastly better than SVN--I'd prefer Hg, but that ship has sailed) at my current employer I'm pushing to have "don't mash your commits" made into policy.

> How the development actually happened is completely uninteresting in git.

"In git" has no bearing on what is interesting in the development cycle, and it's a little arrogant to claim that that's the case. My version control system does not decide what I find interesting.

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

#67

Post by gruseom »

j_col wrote: post #14
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…

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 ;-)

Try approaching git the way you would learn a programming language. It's more like that than an application. Git is just a good implementation of a simple, consistent, appropriate model (or you could say DSL) for version tracking. It offers this model to the user in a straightforward way. But you have to learn the model or git will seem complicated instead of simple.

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

#68

Post by nupark2 »

jeltz wrote: post #64
nupark2 wrote: post #44

Earlier quoted context omitted.

> With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember. svn diff >patch-saved-changes svn revert -R . (work work work) svn patch

I used that all the time when coding with svn, and while not as handy has git stash it is workable. But what I was specifically referring to is the -p flags of various git commands (stash, reset, add, checkout, ...) so you can interactively only stash away what you wish instead of the entire working directory (or an entire subdirectory of it).

When using git in that way, I spend more time mucking around with cherry picking than I would to just treat things atomically.

The tools are more powerful, but they're also correspondingly more complex, and the net value is in my experience negative.

People simply feel more productive as the number of knobs they're turning increases. However, SCM is the least important knob in my day-to-day development. What matters to me is turning around quick changes with associated unit tests and ultimately committing code that works the first time. The less I think about SCM knobs, the sooner I can move on to the next piece of actual work.

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

#69

Post by aeontech »

nupark2 wrote: post #63
aeontech wrote: post #55

Earlier quoted context omitted.

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

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. Most of the features you're discussing encourage that workflow/bad process/bad developer behavior, because they were built entir…

Like I said, neither I, nor my team mates had issues that you describe, nor do I see evidence of this behaviour in Linux development methodology from what I read on the mailing lists. Just because a suboptimal workflow may be created with git, it does not mean you should forgo its power altogether - in fact, one of the main "features" of git that people describe is that it can support more than one way of working in a team.

However, you clearly have your mind made up, so, let us leave it at that.

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

#70

Post by gwern »

xpaulbettsx wrote: post #53
jcheng wrote: post #27

Earlier quoted context omitted.

> 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

What is this, a discussion of Haskell monad tutorials? :)
Post reply on HN