

My Problem with Git: No Abstraction - dogweather
http://www.g33klaw.com/2012/04/my-problem-with-git-no-abstraction/

======
platz
<http://blog.nelhage.com/2010/01/on-git-and-usability/>

"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?” "

------
jerf
Part of why I like git is the lack of abstraction. Lack of abstraction means
the abstraction that isn't there can't leak. I've done some bizarre things in
git, mostly induced by the fact the company I'm working for is still on SVN in
the core. For instance, on two fundamentally different machines based on the
same source tree, I developed a shared feature on one, bundled it all up into
one commit, put some work into integrating it on the other, put some more work
on the original and bundled it up into one new unified commit, pulled from the
second machine and did an interactive rebase to slide the new megacommit under
the integration commits. And it all worked perfectly and exactly as I
expected, complete with dead-on accurate merge conflicts that truly were
conflicts. If you had problems following that description, well, git didn't.

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.

~~~
dogweather
For sure, it's nice to have both available: high level and low level. Like
Ubunutu's user-add and add-user. (Of course, those are horribly named.)

------
lunaru
Git reminds me of the Churchill quote on democracy. It's the worst form of
version control system except all the others that have been tried.

Despite putting up with arcane incantations, I'm not going back.

~~~
wmf
Is Git actually better than Mercurial[1], or did it just win because Linus
forced it on people?

[1] Properly answering this requires imagining an alternative history where
all the massive ecosystem was built around Hg instead.

~~~
jsight
I think there are tons of reasons to prefer Mercurial over git (ease of use on
Windows in the early days being a big one). I also think there are a smaller
number of potentially more significant reasons to prefer git.

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.

~~~
wmf
Which then makes me wonder why they chose to start GitHub instead of HgHub.
Rails may have been the reason; I'm not sure when or why Rails started using
git.

------
wmf
The problem with git wrappers is that there are a dozen of them but none have
critical mass, so all docs and examples are written in terms of bare git. It's
like CoffeeScript — it's fine if you already know JS and use it to save time,
but you can't use it as a way to avoid learning JS.

~~~
natep
Which is why I'm a bit saddened to see another wrapper start up. Does OP even
know about them, or does he think he's the first person to have the idea of
creating a git porcelain?

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.

~~~
dogweather
I admit it - I don't know about any other higher level command line wrappers.
I've only found hub <http://defunkt.io/hub/> which isn't exactly what I'm
thinking of.

Ah hah - I've found just one, although it looks pretty good <http://www.git-
legit.org/>

------
ww520
Is Git really that hard to use? I've used ClearCase, Perforce, CVS, SVN, and
Git. They all have their benefits and idiosyncrasies. Git is not that hard. I
do have to search for its usage and example from time to time for less
frequently used commands, but that's the same for the others.

~~~
rogerbinns
The problem with git is that its defaults are suited to large teams
collaborating. For example if you create tags then push won't push them unless
you specify another flag. This makes sense when there are lots of
collaborators (you don't want everyone's tags polluting) but is annoying in
small groups (you do want to share). This isn't to fault git, but it is what
makes it harder to use.

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.

------
billsix
I don't understand how "mv", with relative and absolute pathnames, is
implementation leakage.

~~~
fr0sty
Maybe it is a UNIX/non-UNIX thing...

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.

~~~
dogweather
No, it's not about mindset or command-line unix culture. It's about interface
design. The command line interface.

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.

------
Cogito
In the project's README it says "g add isn't necessary for staging since g
commit will automatically add objects. In fact, g does not expose the concept
of staging through its interface", which if followed through with will ensure
that this project never gains traction.

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.

~~~
dogweather
Interesting feedback - thanks!

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.

------
jonpaul
Shameful plug: <http://gitpilot.com>

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.

------
Apreche
Git is a Hole Hawg, just like UNIX. That's intentional. Stop trying to change
the software to be easier. Instead change yourself. Make yourself stronger and
better by learning this complicated stuff, and become a master.

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....](http://steve-
parker.org/articles/others/stephenson/holehawg.shtml)

~~~
sopooneo
I think I take your point, but we should only put up with having to learn
_necessarily_ complicated things. So to the extent that the Git interface
reflects a powerful and flexible internal model, I'm with you. But Git is also
_unnecessarily_ complicated. The commands are inconsistent and hard to
remember until you have them by rote. That's a failure of software design.

~~~
fr0sty
"That's a failure of software design."

Or the evidence of a differing opinion on what amount of complexity is
necessary.

------
jgv
The author suggests aliases and while I use aliases daily, I don't believe
that will solve the problem he references. I think providing a better mental
model for what exactly git is doing through visual metaphors is the biggest
help to those learning git. I've found something as simple as the chart here
to help explain the concepts of adding and staging
[http://gitready.com/beginner/2009/01/18/the-staging-
area.htm...](http://gitready.com/beginner/2009/01/18/the-staging-area.html)

