
What git is not - qrush
http://gitready.com/beginner/2009/02/19/what-git-is-not.html
======
100k
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!

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

~~~
100k
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.

~~~
nuclear_eclipse
Between `git help -a` to see all the available commands, and `git help
<command>` or `man git-<command>`, I don't see how Git is any worse than any
other VCS tool. Git is extremely well-documented, and even goes so far as to
provide ASCII-diagrams in the docs to help you visualize what certain commands
do.

Or are you just being picky because Git doesn't name everything exactly the
same as other tools do?

~~~
davidw
I started with cvs, years ago, moved on to subversion when it was good and
stable, and am now starting to fiddle with git. I like it a lot, but it _is_
"fiddly" feeling. I'm sorry I can't describe it better than that, but it's
just a feeling I get from it. Maybe this covers it: I don't get the feeling
that it's going to much effort to "make the easy things simple and the hard
things possible". We know it can do the latter, but the former is not always
true.

~~~
jrockway
_"make the easy things simple and the hard things possible"_

Well, it's Git, not Perl :)

 _I like it a lot, but it is "fiddly" feeling._

To assuage this feeling, I recommend reading the source code for both Git and
Subversion. After you realize the flaky shoestring-and-chewing-gum model that
holds all your data in subversion, you won't worry at all about Git's UI :)

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

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

~~~
njharman
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.]

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

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

~~~
davidw
I'd say git is better for that situation because it's so simple to set up.
That's one thing it really does well. Tons of branches and other stuff are
likely to be less of an issue on small, personal, non-shared projects.

~~~
cstejerean
I don't see why you shouldn't leverage branching in any small, personal, non-
shared project. I got in the habit of making a branch any time I want to try
anything out, after all most of my small projects are experimental in nature,
and branching is perfect for experimenting with changes and ideas that you
might otherwise be afraid to try using a single, linear history.

~~~
timr
I don't get the argument that git is better for branched projects. I worked
this way in subversion for _years_ \-- svn copy and svn merge work just fine.
You can branch! You can merge! Huzzah!

Granted, git is a bit _faster_ for branching (it can take svn a few seconds to
set up a branch, especially if you're doing it remotely), but that slight time
savings is more than offset by the time you spend reading man pages, only to
learn that the various git commands really don't mean what you _think_ that
they mean (and don't get me started on the quirks and inconsistencies and bugs
in git...)

I am not a fanboy -- just a guy who doesn't want to think about his version
control, any more than he wants to think about his toothbrush.

~~~
weavejester
It's not just that Git is faster at branching. The concept of a branch in Git
is conceptually different to a branch in Subversion. In Subversion, a branch
is analogous to a directory, and creating a branch is essentially a cheap and
efficient directory copy. In Git, a branch is more akin to a reference or
pointer to a particular piece of historical data.

The Git idea of a branch is somewhat more flexible than the Subversion idea of
a branch. For instance, say I'm hacking away at a new feature, but I haven't
thought ahead and created a new branch for my commits. A user then comes along
and asks me to fix a bug. In Git, this is no problem, because branches are
just references. I first assign a branch to my current work:

    
    
        git branch new_feature
    

Then I rewind my master branch back to before I started working on the new
feature, 4 commits ago.

    
    
        git reset --hard HEAD~4
    

I then commit and push the bug fix:

    
    
        git commit -am "Bug fix"
        git push
    

Now the user is happy and I can continue working on my feature. But now I'd
like the bug-fix to be included in the history of my branch, since I've pushed
the bug-fix but not my new feature. So I change the 'base' of my branch using
rebase:

    
    
        git checkout new_feature
        git rebase master
    

Now I can continue working on my branch as if nothing had happened.

Using Git is a bit like having a time machine you can use to alter history so
you didn't forget your wallet this morning.

~~~
timr
Golly. That took six commands, history unwinding, a rebase, and a few obscure
flags. I'm beginning to see your point...how in the world would the lowly
subversion user surmount such a catastrophically complicated conundrum without
the raw power of git to save him?

Hmm....

svn copy ./my_code ./my_new_feature; cd ./my_new_feature

 _...hack hack hack...

(user interrupts! a bug! oh noes! must fix!)_

cd ../my_code

 _...fix fix fix..._

svn commit -m "fixed a bug! i rock!"

cd ../my_new_feature; svn merge -c HEAD ../my_code

 _...hack hack hack..._

Oh well. Guess it wasn't that hard, after all. Nevermind.

~~~
weavejester
I think you're missing the point. In your workflow, you create the branch
_before_ you started work on your new feature. In my Git example, I created
the branch retroactively.

If you were to attempt the same feat in SVN, it would get a little messy.
You'd have to first roll back the repo:

    
    
        svn merge -r HEAD:96 http://server/my_repo
        svn commit -m "Reverted last 4 commits"
    

Then create the branch and merge in the previous commit:

    
    
        svn copy ./my_code ./my_new_feature
        svn merge http://server/my_repo/my_code@100 my_new_feature
        svn commit -m "Imported reverted commits to new_feature"
    

Then make your changes:

    
    
        svn commit -m "Fixed bug"
    

Then merge your change into the new branch:

    
    
        cd ../new_feature
        svn merge -c HEAD ../my_code
        svn commit -m "Merged bug fix"
    

And once you've done all that, your commit history looks like:

    
    
        A
        B
        C
        D
        Reverted last 4 commits
        Imported reverted commits to new_feature
        Fixed bug
        Merged bug fix
    

Whilst in Git:

    
    
        Fixed bug   <- master
        A
        B
        C
        D           <- new_feature
    

Now, obviously you'd never actually do all this in SVN if you were sensible,
but that's exactly my point. The Git concept of a branch being a reference to
a commit is more flexible than the SVN idea of a branch being akin to a
directory. Things that are perfectly natural to do in Git are rather more
complex to do in SVN, and leave behind a messy history of merges.

~~~
timr
I'm not missing the point -- I'm saying that your point is silly. You're
fixated on doing everything in the same directory, when in fact it's far
easier _not_ to do it that way, and the only argument you're making for doing
it that way, is that it's more "flexible". But flexibility is not a virtue,
unless you _need_ the flexibility!

 _"obviously you'd never actually do all this in SVN if you were sensible"_

Exactly. You'd never do it. You don't _need_ to do it. You can _get the job
done_ without doing it. And that's what matters.

Git fanboys are hilarious sometimes...every argument is made from the position
that none of the rest of us really understand git, and that if only we did,
we'd fall in love with git in all of it's fiddly glory. What they miss is that
many of us _hate_ complexity, and we avoid complexity that doesn't justify
itself with true functional advantages.

I like simple tools that get the job done. Git makes my life harder; I have to
think about _more_ things to do the same, basic tasks that were made trivially
easy in subversion. That's the point.

~~~
weavejester
I'm not claiming that Git is better than Subversion, or that you should use
it. I'm merely pointing out that branches in Git have other advantages as well
as being faster.

The fundamental problem with Subversion branches, at least in my view, is that
you have to know ahead of time that you want a branch. Perhaps this isn't a
problem for you, but it is for me. Sometimes I find myself thinking, "Hang on,
is this really the right way to solve this problem?" In Git, I can save my
current work in a branch, trot back a few revisions, and try a different
approach.

In contrast, Subversion encourages a largely linear style of development. I
expect some people, like yourself, prefer this approach, finding it
conceptually simpler. And that's fine; I'm not saying that's wrong or bad, or
that you should stop using Subversion. That's clearly what you're most
comfortable with.

But a linear development model isn't for everyone. Those of us who like to
experiment and backtrack tend to develop in a tree-like fashion, branching off
shoots all over the place and pruning the ones that turn out to be a dead end.
For this style of development, Git's branching model is significantly better
than Subversion's.

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

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

~~~
Harkins
Both.

(Your question is too broad.)

------
budwin
i detect bias :)

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

