Gábor's blog

i did a quick check about what source-code-management systems are used by the programming languages that i find important/interesting, and here is what i found:

[EDIT (2008/06/23): (based on the first commenter’s message, it seems the issue i complained about here has been addressed in Git)

i am very interested in distributed version control systems, so i follow the mailing lists of several of them (bzr, git, hg)…

currently my favourite is mercurial btw…

but this post is not about why i chose mercurial.

also not about why distributed version controls are much better than centralised ones (svn, cvs, etc.) (probably will write about this a post at a later point, but not now)

this is about why git is not suitable for me.

intro:

in short, git was created when the kernel developers needed a version control system after the BitKeeper problems, so Linus wrote Git.

it’s a very powerful, and extremely fast version control system. i think, if i would have to decide purely on the features, probably Git would be the winner.

the problem:

but the problem with git is the ..hmmm.. mentality?

it was written (primarily) for the kernel developers originally, and somehow what’s user-friendly for them is not always user-friendly for me.

let’s take a recent example, which i think nicely characterizes the issue:

( the discussion on the git mailing-list )

when you use git, anytime you can do “git diff” which shows you what changed since the last commit, and “git stat” which shows you which files changed since the last commit (this is not an exact definition, but it’s more&less like that).

someone found out, that if he just re-saves a file in the repository without changing it (or in unix-speak: “touch myfile”), then:

1. “git diff” will mention the file, but show an empty diff
2. “git status” will not list the given file
3. if he does “git diff” again (after the “git status”), then it will not even mention the file

so in short, “git diff” behaves differently before “git status” and after “git status”.

when he asked on the mailing list, he was informed that this is not a bug, because for performance reasons “git status” does some things to the repository, which cause that the touched-file does not show up at the second “git diff”.

when he argued that “git status” should be a read-only operation (so that doing it should not affect the behavior of the other commands), he was told that “git status” is not a read-only operation, because in reality it does some internal things in the repository, and also that if this would be read-only, then some things might become slower, etc.

then he argued that while it can be true, that “git status” is not read-only from the implementation point of view, it still should be read-only from the user’s point of view

(for example imagine a simple form of caching of anything.. when you first request some data, they are retrieved, cached and given to you, but when you request it next time, they arrive from the cache. so from the implementation point of view, the retrieval-operation is not read-only, because it writes to the cache, but from the user’s point of view it’s a read-only operation (because to the world outside of the implementation, it behaves as read-only))

but somehow his argument did not get through…

so currently i am not sure if the problem is that:

• the git-developers are not able to understand this distinction between being read-only from the implementation point of view and being read-only from the user’s point of view

or

• the git-developers think that this property of “git status” is not important enough to maybe sacrifice a little performance for it

but whichever is the reason, it just proves for me that git is suitable not for me.