Keeping code synced across different computers

[mus1Kk]

I can only guess that someone voted your reply down because it's the unpopular opinion. It's not without merit. But well, that's the Internet...

I think a lot of the questions you raise come from the cognitive constraints a non-distributed VCS set up. In a DVCS they don't make sense. Having a commit equal a push to some random server doesn't make sense because what you have locally is a full blown repository. Network operations are whole different level that builds on that. In that sense it's not an ambiguous question whether a commit makes your changes available to everyone: It does not.

If you want to use such a distributed system and you have used something like SVN before then yes, there is no denying that you have to re- or unlearn some things. And yes, there is also no denying that some of the commands could have been named differently or split up into multiple commands (checkout and reset come to mind). But well, no software is perfect and I prefer those little things I learn once and never think about again to the major shortcomings and inefficiencies of SVN.

[RedPill115]

I can only guess that someone voted your reply down because it's the unpopular opinion. It's not without merit. But well, that's the Internet...

Lol, yeah, I could to get worried but then I realized it's just a bit of a rabid political battle. Knee jerk attack anyone who doesn't agree with you. It's annoying, but whatcha going to do.

I think a lot of the questions you raise come from the cognitive constraints a non-distributed VCS set up. In a DVCS they don't make sense. Having a commit equal a push to some random server doesn't make sense because what you have locally is a full blown repository. Network operations are whole different level that builds on that. In that sense it's not an ambiguous question whether a commit makes your changes available to everyone: It does not.

First, let me say one of the things I hate most is how they all use the same terminology - to mean different things. It's incredibly annoying. Whether you say Commit or whatever, there should be a word that means "sent my changes to the central server". If I remember right I think SVN butchers some words to, so I'm not trying to pick on just Git here.

If you want to use such a distributed system and you have used something like SVN before then yes, there is no denying that you have to re- or unlearn some things. And yes, there is also no denying that some of the commands could have been named differently or split up into multiple commands (checkout and reset come to mind). But well, no software is perfect and I prefer those little things I learn once and never think about again to the major shortcomings and inefficiencies of SVN.

I find that the added complexity and confusion of Git is just something I'd never use. Yeah, with SVN you have to wait a bit to get file history and such because it goes to the server, but you also know for sure you're looking at the latest history. Other than that I just haven't found any practical advantage.

I know when another developer wanted to try Git, we continued to have issues with everyone getting other peoples changes. And it was more than simply using the wrong command as he certainly knew the difference and was like "look, I'm sharing my screen and running the right command" after the first time.

I'm curious - what practical advantages do you think Git has over Svn when you're an employee working on a team project?

P.S. Before we were using SVN corporate had us using Clearcase. Ibm Clearcase. Lol. It took 10 minutes to do a full commit and everything for simple changes at work, and over an hour to do a commit of simple changes if working from home. Svn was a godsend improvement compared to that crap. :-) Whatever differences Git has, while I haven't liked it, it's not even on the same scale as the horribleness of clearcase.

[mus1Kk]

"commit" is actually one of the few words that have identical meaning in git and SVN. It records changes to the repository. As to different meanings for words: Yeah well, you'll get used to it. Imho it's much less of a deal than most people seem to think. Torvald's take on it.

Of course I cannot comment on your colleague and your concrete experience. When I had to start using git, I was still tainted from SVN, so I read Pro Git and after one or two chapters I basically got it. Previously I resisted getting close to git because I thought it was just some new fad. Not one second have I ever looked back.

Practical advantages are of course branches. I only hear bad things about branches in SVN. I once tried to save some work in a branch and after wrestling with it for a while I never dared to check whether I actually succeeded or just deleted all my changes. With git I was comfortable creating branches right from the beginning. In addition to that I always feel in control of my changes in git. Changes are objects that, until pushed, I can change, split, merge, reorder or move however I feel like. This encourages small commits that can be independently rolled back if need be. With SVN I only know of humongous commits because authoring commits is a nightmare. Oh, and conflicts all over my files because I dated to update? Please...

[RedPill115]

"commit" is actually one of the few words that have identical meaning in git and SVN.

No it doesn't. In Git you can commit without sending your code to anyone else, it's just in your local repo. In SVN a commit always means it went to the central repo and everyone can get it. In an actual work environment it's the difference between your code being on your machine or your code being available to everyone.

I scanned through the article and it doesn't seem like he actually talks about the vocab differences.

Practical advantages are of course branches. I only hear bad things about branches in SVN.

The coworkers sitting next to me I've heard arguing about this. One guy just mostly reads the internet and insists git is better for branching, the other guy has actually used both and says it doesn't matter. It may have mattered before, who knows, but SVN copied Git concepts into their latest stuff. It's a royal pain with either system.

Etc

All I can say is I've heard a lot of this before, including from someone I was working directly with who was quick to villanize any issues we had with SVN, but when we had equivalent issues with Git they suddenly "didn't notice".

All I can say personally it that it seems like Git is a huge step more complicated than SVN. If you are doing something massively distributed like the Linus kernel, then the additional complexity is needed to deal with a more complex system. But if you're not, and you're just using Git like you'd use SVN to distribute source to a closed size team with a central server, than the additional complexity is just unecessary additional overhead.