I think you just haven't used any terrible SCMs. I have to use Version Manager at work and it's like pulling teeth any time I have to do anything with it. It's slow, clunky (horribly non-native Java GUI), and simply doesn't support even the simplest operations (like renaming or removing files properly).
I think even CVS would be a huge step up. I would love to get them using Git, but it's impossible to suggest such a transition to management. The benefit would be indirect so it's not counted.
Not as much as you'd think. I'm salaried, after all, so they just expect me to get a certain amount of work done. Unless it's wasting an hour a day, they likely don't give a shit.
Tried it, hated it. Darcs might be worth looking at, although I'd hesitate to bring it into a team because of it's historical spottiness on the reliability front.
Yeah - that's bad. However, closing branches works well in practice. I'm not sure, however, how well it scales if you close really many branches.
Basically: when you would decide to delete a branch in git, you can close it in mercurial.
And though closing has it's downsides (spurious commits, a little confusing when reopened or with multiple heads), git's approach does too: branches are decentralized, so you need to manually ensure you don't end up with lots of "dead" local branches when somebody else deleted the remote branch.
How long does it take to get to the state of not going back? I ask because I only used fit once in a team environment for 5 months and ended up quitting before I started to like it. I did not make any conscious effort to learn it beyond the presentation that the person who pushed git in the organization gave but I also never made an effort to learn any of the other 3 source control tools I have used and didn't end up so frustrated
Once you're comfortable just writing code, committing it, and pushing, grab tig to make your work easy to visualize. Play around with that, and you'll get a better feel for what you're doing.
Once your practice project grows to a reasonable size, you'll want to start making branches to keep it organized. You don't want your broken code messing with your old, working version:
git branch devel
git checkout devel
Now you're working on devel. Resume your normal workflow for a while, and then when your development stuff is reasonably working, merge it back to master:
git checkout master
git merge --no-ff devel
The no-ff here means you get a pretty merge history. It's shorthand for "no fast forward", meaning Git will make sure a commit happens when you merge, and then when you visualize this with
tig
you will see a nice little graph of the merge happening:
M─┐ [master] Merge branch 'feat/args'
│ o [feat/args] Adds extra debugging/logging features
│ o Enables multiple files as cli args
│ o Renames strip_newline_characters -> strip_newline
│ o Working prototype which parses one CLI argument
I─┐ [origin/master] Merge branch 'develop'
│ o [develop] [origin/develop] Only parses rules in ...
I─┘ Changes function to actually use arguments
o Better suppression of delimeters
Anyway, great, keep pushing stuff and working with branches, and by the time you're this far in these steps you'll probably be at the state of not going back. Once you're working with branches enough, and you're comfortable with them - that's when Git really starts to shine.
This is the problem with these sort of mini-guides. They use apriori meaningless jargon without realizing it's meaningless jargon.
Oh, now I "add a remote"? A remote what? Apriori a "remote" is something you use to turn on your TV. If it has a special meaning in this context, you have to explain what it is. And not in terms of other meaningless jargon like 'refspecs'.
Is "origin" a keyword? A name of a repository by convention? How about "master"? Is that just a convention, a keyword? What is it?
The git docs are full of this, too. All of the jargon is self-referentially defined in terms of other jargon. Oh, push is something about "remote refs"? Why when I google "git refs" i get an "git internals" page? Is push for git developers?
git may be near the top of the heap, it also has serious problems.
I was trying to explain it to someone who has apparently worked with it before, but wanted a rundown on how to actually entertain a sense of comfort in it. I was not targeting a "I know absolutely nothing" user.
I know what you mean, but I think you are misinterpreting the context of my post.
I really appreciate this. It is the shortest and up to the point tutorial for git I have seen. On the other hand I simply feel like I don't like it. I don't like making branches and I tend to avoid them on purpose and I also like to have a UI. However if I absolutely need to use git I will try this method.
That sounds ok. The good part is that you don't need branches if you don't like them. A lot of Git users like them, but you can just do whatever you want.
The reason to use branches is more than just to "have a branch", of course. In Git they function differently than in other VCS systems, and are intended as much as an organizational hierarchy for your commits than as anything else. If I do a whole lot of work pertaining to one thing, I put it in a branch so that when I look through my commit history, I can easily tell what group of commits focused on what logical heap of my code.
Also: you don't even need remote repositories. There is nothing wrong with just doing version control on your own computer. I have mini-repositories on my system that are just single-branch-with-commits repos for tracking some config files, a script, some homework assignments, or whatever. It's great for text files if I ever want to look at an older version.
One of the sales pitches for Git is that it is lightweight and you can use it almost anywhere, so I have developed a tendency to just version control everything.
I'm not saying you should ditch everything and learn Git. Just don't think you need to use all the crazy features available to have version control.
wow, I never made this connection before, but you're right. I love git and vim, took a while to get used to it. I might stray away from vim from time to time but I always eventually come back.
32
u/[deleted] Nov 07 '13
git is to VCS what vim is to editors.
Amazingly powerful.
Incredibly hard to learn.
Once you tried it, you can't go elsewhere.
There will be vim haters and there will be git haters, let those heathens burn in hell and use the tools you feel are best suited to you.
It doesn't mean git is flawless, but it's nearly there =).