My Problem with Git: No Abstraction
g33klaw.com
g33klaw.com
"Fundamentally, the way (most) people learn and think about subversion is different from the way git experts think about git. subversion’s internal model is fairly complex, but you are not expected to understand it. You just have to know the half dozen commands you’ll ever need, and you use them, and everything is fine.
Git’s model is fundamentally fairly simple (a DAG of immutable commit objects where branches are named mutable pointers into it), but you are expected to understand it fully to use git effectively."
...
" The other, perhaps more fundamental reason, is that git is designed to be infinitely flexible, and so it’s fairly rare that you can give an answer for “How do I do X with git?”, since the answer will often depend on, “Well, what are your project’s conventions?” "
Yes, to the extent that may seem like a bizarre workflow, it is. I know. There are additional constraints I did not describe. The point is, it's a workflow that git doesn't close off with leaky or over-limiting abstractions.
That said, I totally agree that this is irreducibly a strength and a weakness at the same time, and YMWV. But I'm glad it's around so I can use it. It's saved my bacon more times than I can count.
Despite putting up with arcane incantations, I'm not going back.
[1] Properly answering this requires imagining an alternative history where all the massive ecosystem was built around Hg instead.
Then again, even before that many big projects were falling to git from the likes of svn like Xorg and others. So it's hard to say.
Maybe going back to the mailing lists of some of the big conversations might help shed more light.
But yes, usually what can make a piece of software great is having some good applications, and the linux kernel was a great place for git to grow up and show off on. Maybe mercurial just suffered from less of that. Mind share seems to grow exponentially.
- tag handling in hg is (was ?) horrible
- I think using integers for revisions, even if just in the UI is a very confusing feature, as it gives a false sense of familiarity (hg like every DVCS I know internally uses unique ids for revisions).
- too many ways to do branching that all have +/-. While you can do it in a similar way to git, you don't have all the UI that makes it so useful.
- the notion of tip is a major UI wart as well.
On the + for mercurial: definitely better support for cross platform, more consistant UI, better performances on windows.
But I think it's almost completely impossible to separate the success of Git from the tools ecosystem. I really think Mercurial would have been at least as popular as git in the long run if it had something as good as Github behind it from the beginning.
The benefits of Github are truly astounding.
I'm attempting to first spec it out in an appropriate way: writing the docs first, and so that the new abstraction is maintained. However, the new commands should re-use git command knowledge and not change it arbitrarily. It should fail well.
And then there's always that 1 time you need to do something that git can do, but your porcelain can't. Then you have no choice but to learn git the 'right' way.
Personally, I think I understand git too well for picking up a porcelain to be useful to me, which also makes me a bit sad.
Ah hah - I've found just one, although it looks pretty good http://www.git-legit.org/
I'm also confused by the github love. Exactly what is it that people think is so good about it? The ticket tracker is terrible (no prioritization, no attachments), the wiki doesn't have table of contents/document structure, you can't cross link between projects etc. As an example Google Code does quite a bit better on those issues, and they let you have multiple repositories per project so you can share the wiki, tracker and downloads as makes sense.
I have been using UNIX-type operating systems almost exclusively for the whole of my professional life so have zero appreciation for the troubles people have when approaching UNIX tools from a Windows (or whatever) mindset.
Git (and the whole toolchain and OS for that matter) is much more about DWIS than DWIM and that does not click for a lot of people.
All of the established unix commands do a particular conceptual thing well. "sort" always sorts. Its options affect how it sorts.
But git ... "git checkout" can switch the working branch. "git checkout" can rollback code ... depending on the specified options.
He would want "mv" to take 2 params: (1) old file path (e.g., "/users/dev/foo.clj", and (2) new directory (e.g., "/users/lib").
But yes, for this discussion, a higher level version would probably split it into two commands: rename and move. And these would only do those particular functions. With that there is no implementation leakage. For the few times that you'd want to move and rename, you'd need to use both commands.
> REN [drive:][path]filename1 filename2.
> Note that you cannot specify a new drive or path for your destination file.
For people with a mental model of files and directories built from using a GUI with windows and folders this does seem to be implementation leakage since you have to know that renaming is moving because of "how the filesystem works". They think of the file name as file metadata and the file contents as the file.
If you have a mental model built around unix-y file management then you probably think of the file path as the file and the fact that renaming and moving are the same thing seems obvious.
mv *.jpeg *.jpg
The staging areas, though foreign to newcomers, is one of the most liked features of git (I should look up the git survey results, but I'm lazy). In fact, it is core to many excellent features of git, not least of all the ability to interactively select which parts of your work you want to commit, even down to different hunks in the same file. Ignoring this powerful concept makes git a less powerful beast, and hobbles it unnecessarily. To say that the concept of staging is complex is fine, but surely throwing it out is the wrong answer.
I started off with that idea because I personally rarely use this feature. I pretty much always commit all my changes. And so I only change things that I want to commit.
I'm sure I picked up this habit from my svn days. I'll look around for those survey results.
We seek to fix the abstraction aspect by focusing on the difficult of collaboration. It's working really well for us. We'll be launching our beta test soon.
You can't drive a car with a manual, the solution isn't to get an automatic. The solution is to learn to drive stick.
For those unfamiliar with the Hole Hawg:
http://steve-parker.org/articles/others/stephenson/holehawg....
I never saw a Hole Hawg.
I kinda wonder if that's the story you tell yourself to explain why you were hanging in midair from a drill.
Or the evidence of a differing opinion on what amount of complexity is necessary.