What git is not

http://gitready.com/beginner/2009/02/19/what-git-is-not.html

by qrush • 17 years ago

52 40 17 years ago

100k4• 17 years ago

The reason I think git is complicated isn't because it's complicated conceptually. It's because the commands are intentionally different from other SCMs, which is highly annoying when you know what you want to do but can't figure it out.

For example, how do you revert a file in your working directory?

Oh, git checkout HEAD file -- obviously!

jrockway2• 17 years ago

You seem to think that other version control systems don't have this problem.

Let's consider subversion. Let's say you want to revert commit 1234. You just say "svn revert 1234", right? No. svn revert does something completely unrelated.

In git, "git revert 1234" does revert changeset 1234.

So you see, you actually have to learn about the version control system, regardless of which you choose.

You can't just make stuff up and expect the computer to understand what you mean.

100k4• 17 years ago

Agreed! But I already know SVN, and Linus intentionally made git different than the other SCMs because he thinks they suck.

I think that's annoying.

And there's no way you can tell me that the git command set is more discoverable than, say, Mercruial's. Many common, every day commands in git are very difficult to figure out without a lot of searching and reading. This is not true with Mercurial.

lnguyen• 17 years ago

All SCM tools will frustrate anyone migrating from one to another. I've done migrations among most of the major commercial SCM tools and had to write training documentation for developers.

You do have to realize that if the underlying model for version control is different, then commands and terms will be different even if they share the same name like "checkout." And what you think you can or want to do might not be what you really should do.

So expect some initial frustrations and a lot of referencing of the man pages, documentation, blogs. You're going to have to unlearn a lot of behaviors that may be second nature to you. But at the end, you'll get a much better appreciation of what each tool gets right and an understanding of their limitations.

pstinnett• 17 years ago

For someone who doesn't have much experience with SCMs, is it worth learning Git or should I learn SVN? I get the general idea behind both - just not sure what I should dive into.

bisceglie• 17 years ago

learn both. get comfortable with both. i don't see SVN being abandoned, and a lot of companies/projects use it. i like GIT over SVN, but am glad i'm comfortable with both.

arebop• 17 years ago

Contrary to what seems like the prevailing view right now, Git is not strictly better than SVN. Some reasons to use SVN are at http://blog.red-bean.com/sussman/?p=90.

It sounds like you want to use SCM in a personal (not collaborative) capacity. I think both SVN and Git are suitable for this purpose, but maybe Git has the edge because its philosophy doesn't privilege a repository.

old-gregg• 17 years ago

I believe Git is strictly better than SVN even for one-person-never-share style of development simply because of much, much, much better branching/merging.

Being able to maintain and merge multiple branches without any effort is a huge, in my opinion. I don't think you can get away without using at lest some branching features in any project: at the minimum you'd need to maintain tags for released versions and keep "latest stable" from "development/experimental" code separated. And this is where Git shines.

I'm not saying SVN can't do branches or tags, I'm saying it takes more effort, and tools in general are supposed to make hard things easy.

dasil003• 17 years ago

I think the git repository model is pretty much a clear win over the svn repository model.

Subversion would be better off writing a front-end on top of git. The subset of a repository issue is indeed something that git still doesn't handle very elegantly, but I think ultimately if the right front-end was built, the underlying git repo model would prove better even for this case than the subversion model.

kragen• 17 years ago

It seems like the issues described there can be dealt with in Git by dividing things up into submodules, if submodules work well. (I haven't used them much.) They also only seem to apply to really big projects — dozens of contributors, and dozens of gigabytes to terabytes.

mechanical_fish2• 17 years ago

A very useful link there. Quite pragmatic. It tells us that Subversion's experts believe its future lies in:

- "Huge projects where putting all the current source code on everyone's machine is infeasible."

- systems with very complicated permission schemes where "you just plain aren't allowed to give everyone all the data"

- "organizations whose users need to interact with repositories in complex ways... These things are probably most useful to the corporate world, and to governmental and military organizations." [Karl Fogel]

So, if you recognize yourself in any of those groups, learn SVN. But otherwise I'd start with git. You can pick up the necessary rudiments of SVN (or, god help me, CVS) later when you need them.

ichverstehe• 17 years ago

I have never used CVS/SVN (beyond very, very basic checkin/checkout) so git was my first SCM, and looking back at the last one-and-a-half year, it has only done me good.

100k4• 17 years ago

If you have a choice about what SCM to use, I would just learn Git or (my favorite) Mercurial because as others have pointed out, they are just better than Subversion, even for single user access.

Both git and hg are easier to set up, faster, and feature better merging.

If you have to work with people who are using Subversion already, you should understand how to use it effectively, too.

theBobMcCormick• 17 years ago

Neither. Learn bzr. It's much easier than either Git or SVN.

mooism2• 17 years ago

But much slower.

I switched from bzr to hg when I decided I wanted my prompt to include a count of unchecked-in files. `svn st` and `hg st` are effectively instant; `bzr st` was taking about half a second to a second. That kind of delay on my prompt was highly annoying, and it was enough for me to switch to hg.

budwin• 17 years ago

i detect bias :)

glazz• 17 years ago

And what about bazaar? Is it better or worse than git?

Harkins2• 17 years ago

Both.

(Your question is too broad.)

jodrellblank• 17 years ago

Just to reference another HN discussion "My web is text based" (here http://news.ycombinator.com/item?id=488030 ) - this is the sort of topic where I think video and screencasts would be helpful.

Not a screencast of someone typing DVCS commands into a shell, mind you, or a video of someone talking about DVCS that could be transcribed to text with no loss of explanatory power whatsoever, or, $deity forbid, a video of someone reading inaudibly from illegible slides.

A decent animated introduction to distributed version control explained by characters worthy of Pixar, set in a world of fantasy physics where things can pop into and out of existance.

DVCSs do things which are non linear, text and talk are extremely linear. Text and audio shouldn't be the only two forms of media on the web, video explanation shouldn't mean linear explanation.

MartinMond• 17 years ago

There's http://gitcasts.com/posts/railsconf-git-talk

It helped me to actually get git (incidentally that's also the talk's title).

Don't let the "rails" in the URL mislead you, it's mostly about git and you can easily skip the part about Rails.

njharman2• 17 years ago

These always (fail to)address the same old issues. I switched to SVN for some specific features. I've looked and not been able to get definite answers if git supports these. In fact I've mostly gotten "if you don't do it/use it our way you're stupid, go away".

proper directory move/rename history

proper binary handling(that is no merging, newest file wins)

proper line ending handling (that is default to convert to local system's standard but overrideable per file/file pattern)

proper permission handling (track permissions and set them on check out/update/whatever you call it)

git seems focused solely on source code and heavily towards the Linux Kernel development process.

I use svn for website deployments, tracking changes to servers' filesystems(parts thereof), and occasional source code. I don't use anything close to the Linux Kernel dev process.

Harkins2• 17 years ago

I think in this case the word "proper" means "the way that seems intuitive to me". This is not bad, but other people have made different technical decisions. Adding the word "proper" tries to make these into quality judgments into opinions, but that's still what they are.

I hope you find a system that works as you prefer.

njharman2• 17 years ago

Yes I agree. I meant and hoped that the (explanation in parens) would be interpreted as my opinion on what was proper. Believed the construct "proper ... (that is ...)" was clear, guess not. Oh, and thanks for not answering any of my questions and ranting off topic.

[an aside; I don't believe in "proper", there is no proper there is only "proper for me", never "proper for you." One should reject others' attempts to inflict "what is proper" on them. Good job btw. My use was to alter people's thinking or simply make them think, even subconsciously. Language is a virus.]

DannoHung• 17 years ago

The only thing I worry about with git is getting really raw developers who have never, ever used version control up and running in a semblance of a reasonable manner of operation.

I mean, I know people who were resistant to using subversion because they didn't understand how it was supposed to work. I sort of shudder to think about the mental reaction to being dropped into git. Because of this I originally supported Darcs. I still would if they could clean up some of the patch resolution problems that they have and the Darcs GitHub-like got halfway decent (maybe with Camp).

Source Control is one of the fundamental tenets of development and getting newbs trained on it is so incredibly important. We, collectively, can't afford for it to be a tough thing to get a handle on. Even if it takes time to really understand, it needs to be easy to get going and using the tool in a good semblance of the proper manner.

What git is not

Related Stories