
What’s wrong with Git? A conceptual design analysis - colinprince
https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/
======
Lazare
The issue here is that git is:

1) A tool for managing collaborative work through a beautiful distributed
graph theory tree model[1]...

2) ...with a very, very difficult to use UI. Unfortunately:

3) A good, intuitive UI for manipulating the underlying model without ignoring
edge cases or removing functionality is extremely difficult, and indeed,
nobody has done it yet.

So you periodically see these articles pop up decrying the UI, but nobody ever
makes a great UI that wraps the underlying tools. This article talks
positively about gitless, and it's a great tool, but it gets a good UX only be
hiding/disabling large chunks of functionality. And like most tools...

4) Git suffers heavily from the 80/20 rule[2].

I'd say 95% of the time, I'm using maybe 5% of git's features. But the other
5% of the time, I'm using another 1% of git's features _but it 's always a
different 1%_. I might go weeks without needing to cherry pick a commit, but
when I need to, I _really_ need to...and gitless doesn't support it (or most
other "complicated" features). But the reason git beat out the competition
isn't git's excellent UI or large marketing budget, it's that those features
actually provide significant value.

And so we get a slow drip of articles like this. "Man, it would be nice if
there was a better git UI that had all its features!" It would indeed.

[1]: [https://xkcd.com/1597/](https://xkcd.com/1597/)

[2]:
[http://www.joelonsoftware.com/items/2006/12/09.html](http://www.joelonsoftware.com/items/2006/12/09.html)

~~~
matt4077
This article isn't complaining about the UI. They are very specifically
attacking the /concepts/ that git uses – see the quote I posted further down
in this thread.

It appears as if the complexity of git has created a sort of Stockholm-
Syndrome, where people mistake the flaws of the system for symptoms of its
magnificent power, and dismissing all criticism with an attitude of "let the
hobbyists have something with a shiny GUI, this a tool for professionals".

But what people are asking for is /not/ a shiny veneer hiding the complexity,
but a rethinking of the concepts that git uses. "Concept" here means mostly
the mental model people form of how git operates, but that is often linked to
the terms used and the internal structure.

As an easy-to-grasp example, filesystems generally operate with the "tree"
concept. Note that there's nothing mandating such a structure – you could
create a fs that's based on tags instead. Or weaken the tree metaphor by
allowing cross-connections (i.e. linking). But given the choice of one
concept, it creates certain assumptions about how to operate the system. And
when those break down, people rm -rf and start over. Way to often.

~~~
nhaehnle
True that they focus on concepts. The thing is, the overview diagram of git
concepts on that page (which is in turn taken from the gitless paper) doesn't
even mention _commits_ as a separate concept even though they are one of the
most important concepts of git (and the ability to quickly juggle commits is
crucial to the original git workflow).

That makes me a bit sceptical about whether the authors really thought through
all the various use cases of git, i.e. those 5% that the GP comment talks
about, and about their conclusions.

------
jogjayr
> the elimination of staged versions;

So you can't selectively stage hunks and discard others? Or stash them after
making a commit of the ones you staged?

> the elimination of the concept of Stash, and stashed versions;

This eliminates the possibility of quickly putting away work in progress to do
an impromptu demo at your desk, or answer a co-worker's question about the
current master, or (for git newbies) working effectively with git-svn (in
companies where SVN is used) without needing to learn about local branching or
rebasing.

> Thus, it is as if there are multiple working directories (one for each
> branch),

So...like Subversion? Ew.

Does git have sharp edges? Absolutely. It's a tool meant to be used by
professionals (or skilled hobbyists) to do work and build things.

I'm all for making things simpler to use, but putting training wheels (or
guardrails) on a product meant for an expert user seems...counter-productive
to me. To me it's like saying "Gee that cockpit has an awful lot of dials and
instruments and things, we could probably take out a lot of the complexity if
we assume that pilots will never have to deal with a stall" (I know nothing
about planes)

I am also willing to admit that perhaps I'm too wedded to the time investment
I've put into learning git and therefore assume that anything that attempts to
make git simpler is flawed in some way. Maybe gitless really is the future of
git.

~~~
gcp
_So you can 't selectively stage hunks and discard others?_

As other people have pointed out, most new version control tools can do this
_without_ a staging area.

 _This eliminates the possibility of quickly putting away work in progress to
do an impromptu demo at your desk,_

No it doesn't, and they explain how. With combined branches + stashes, you'd
do a checkout of a new branch from the commit before your stashed changes.

 _So...like Subversion? ... putting training wheels (or guardrails) on a
product meant for an expert user seems...counter-productive to me._

Did you even read the article or the original paper?

~~~
marcinkuzminski
The latests iteration of hg crecord which is an interactive selection tool for
chunks (see it in action here:
[http://g.recordit.co/BfbSa7cMXn.gif](http://g.recordit.co/BfbSa7cMXn.gif)) Is
far far better than git staging area. Intuitive to use, i can submit hours of
code in few nice selective chunks really easy.

This sole function built in is a game-changer in mercurial for me.

~~~
glandium
It strikes me there's nothing inherently mercurial specific to this tool. This
could very well be ported as a UI for git add -p.

~~~
marcinkuzminski
I think GIT staging area wouldn't make it so nice to use in the end. Unless
the whole thing is abstracted more, but then we get into the gitless
discussion again.

~~~
nhaehnle
I think it already exists as a graphical tool for Git, check out `git gui`.

------
wirrbel
The interesting thing about git is, that while it is heavily criticised for
begin difficult, it is such a huge success.

Most of the time, criticism of git can be summarized as "Bad user experience",
which is often blamed on git exposing its implementation details. I.e. most
git criticism proposes that the backend of the VCS should be "private" and the
user should see a carefully designed UI, that is optimized for workflows.

I think we don't need to redesign git in such a way, for the mere fact, that
we already have a mature, distributed version control system that has a
carefully designed UI and has a core that is opaque to the user: mercurial

In fact, given mercurial's age, the availability of github-like hosting
services (bitbucket offered mercurial hosting for years) raise a very
important question, that I would like "git-reformists" to answer as part of
their critique: _Why has git won more market share than mercurial?_

My feeling is, that part of what makes git hard to new users is a "killer
feature" for intermediate and advanced users. I.e. having a basic
understanding of how git manages its data makes hardly leaves me with
situations and repository states that I cannot resolve. Whereas in mercurial,
I feel pretty much lost when I want to do something that has not been an
implemented workflow.

Maybe, now that we know a lot more about DVCS workflows than we did at the
time when mercurial and git were young, a new workflow-oriented VCS might make
better workflow choices. Until then, I happily stay with git.

~~~
pjmlp
> Why has git won more market share than mercurial?

Because Git is used by Linux and was designed by Linus.

Those facts alone are good enough for most people to choose git over something
else, not the technical ones.

Just like UNIX and JavaScript, technically better is not always what wins.

~~~
andai
UNIX and JavaScript?

~~~
gcp
They're (counter)examples. Bad things that won.

"Worse is better" etc.

~~~
MEHColeman
Genuinely curious: which OS ought to have beaten UNIX?

~~~
prewett
The Unix team created Plan 9 to supercede it, so that's the logical choice.
BeOS had a lot of fans, too.

(Completely unrelated, I just discovered that the Plan 9 logo bears a striking
resemblance to the Go logo [see the Wikipedia link]. Given Rob Pike's
influence, I'm sure that is not a coincidence.)

[1]
[https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs](https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs)

------
mooted1
Most of the comments here are missing the point. The functionality and
architecture of git aren't what's being criticized, but the way this
functionality is presented. In fact, gitless if built on top of git's
architecture.

As far as I can tell, gitless still embraces git's distributed and incremental
core. It just packages it in a way that's easier to digest. If you're a
veteran and know your way around native git flawlessly, gitless probably
presents little value. But if you're a notice just learning the tool, gitless
can probably accelerate your learning curve without sacrificing
functionality—you can still bypass gitless's abstraction layer when you need
it.

~~~
gcp
I'm not sure that combining stashes and branches wouldn't be handy for
advanced users either.

~~~
petre
Why would I commit my breaking, work in progress experiments to a branch?
Isn't that what stashes are for?

~~~
aninhumer
Because sometimes stashes are longer lived than we expect, and they're hard to
work with if you need to do anything more complicated than popping. (Like
resolving conflicts.)

I find that making a work-in-progress commit, and then resetting later ends up
saving a lot of hassle overall. Having support for this beyond aliases
(including putting that commit in a new branch) would be nice.

~~~
petre
Okay, points taken. But git enables me to commit expermiments to a branch
anyway _if_ I decide to. Gitless' lack of stash would force me to commit
experiments to a branch.

------
xedrac
I personally think Git's staging concept is one of its best features. Yes it
is different and increases the learning curve somewhat, but it also provides a
lot of flexibility in what you commit. For anyone that thinks Git is too
complicated, consider using Mercurial.

~~~
Ace17
If my repo contains modifications I don't want to commit, I git-stash those
modifications. I find it to be a lot safer: at least I can run the build +
testsuite on what I'm actually going to commit, allowing the prevention of an
incomplete commit (which means in practice, I nearly always use "git commit
-a", and I find the index pretty annoying).

~~~
tomp
Haw can you partially stash a file?

~~~
glandium
git stash -p

------
bsandert
Git only started really clicking with me when I started thinking of most of my
actions as graph building and traversals. It also helps to realize that for
most intents and purposes, commits in git are immutable and "destructive"
actions such as rebase don't _actually_ rewrite history, but rather create a
new path in the graph and moves your branch pointer to it, leaving all
previous commits intact (though potentially hard to reach and subject to
garbage collection).

------
FuNe
This reminds me of a well known comic:
[https://xkcd.com/1597/](https://xkcd.com/1597/)

~~~
kinkdr
Thats really funny, because that's exactly how I use git. But I only blame
myself for never finding time to read up a bit and understand its concepts.

------
detaro
recent discussion of the gitless project, which is presented as in this paper:
[https://news.ycombinator.com/item?id=12621837](https://news.ycombinator.com/item?id=12621837)
(300+ comments)

------
Tobu
The blog author doesn't understand Git that well:

    
    
        git add foo.rb
        // continue working in foo.rb
        git commit foo.rb
    

will commit the latest version of foo.rb.

That's because git commit handles its arguments by add-ing them to the index
(staging area) before doing the actual committing.

I'm not so sure about the conceptual graph from the paper, either. The stash
is a commit, it doesn't have anything to do with file states.

~~~
aninhumer
No, the author is correct. The add command adds that version of the file to
staging, so subsequent changes will need to be added as well if you want them
in the commit.

~~~
nickez
No, you can read the following in the man page of git commit:

3\. by listing files as arguments to the commit command, in which case the
commit will ignore changes staged in the index, and instead record the current
content of the listed files (which must already be known to Git);

~~~
aninhumer
Oh indeed, you're right. This didn't occur to me because I've never had a
reason to use `git commit [path]`.

And I don't know if I'd call this error evidence of the author not
understanding git, as much as I'd call it further evidence of the
inconsistency they're highlighting.

------
chmike
This presentation of gitless makes it attractive. I'll give it a try.

One of my problem for which I didn't find a satisfying solution yet is to
efficiently see the changes in commits and reshuffle and merge them.

Actually, when I do a change, I offten see and fix typos and other bugs or
refactor code in the same step. So my commits tend to be a compilation of
unrelated changes instead of clean atomic commits. It is a boring work to
split these commits into nice and clean commits.

I know I should commit frequently (small changes), and then afterward merge
related commits. But that is not easy with git and I suppose gitless too. So I
tend to do big commits which is bad. Any suggestion how I could improve my
commits ?

~~~
aninhumer
This might already be what you're using, but just case (and for other people's
benefit) `git rebase -i` is _very_ helpful for reordering and combining a
bunch of small commits. (I mention it because you're referring to "merging"
rather than squashing or fixups.)

It opens a text file listing your commits prefixed with a command, which you
can reorder and edit to change the history in one go. It's not completely
painless, and I still prefer to do operations one at a time with it in case
there are any conflicts, but it's still better than the alternative. (I'm not
even sure what I do instead...)

~~~
chmike
Thanks. I saw that gitless has the option -p that is documented as allowing to
select parts of a file to commit. I'm curious to test that. It seam possible
to reshuffle commits using `gl fuse` which is a kind of `git rebase`, but
there is no interactive mode as with rebase.

Just found a limitation in gitless. I can't publish tags.

------
FloNeu
_Just some git love_ Didn't read, but there are so many articles out there...
i started working with git from console ( when i didn't use the console that
much ) and still compared to tfs, subversion etc. it felt like haven. I
currently have to use SourceTree at Work... damn it makes git feel so slow...
Somebody experience with
[https://www.gitkraken.com/](https://www.gitkraken.com/)? Any point in trying
it out? All the best

------
msimpson
While Gitless is a positive effort to rectify some of the shortcomings of Git,
I wonder why the authors found it necessary to construct a veneer over Git
instead of simply forking it entirely. While the veneer is nice on a trial
basis of such functionality, to continue in that fashion for production use
would require constant maintenance to remain in sync with any core changes to
Git and its surrounding tool chain. A fork would be cleaner, yet interoperable
with Git repositories and separate.

------
initram
This is a really cogent description of what I've felt about fit for a while
but was unable to articulate. It's also written in an non-combative way.

------
jgalt212
I feel about git the same way I feel about emacs.

In the time it takes to master git/emacs, one could have accomplished
something seriously impressive.

Of course, this analogy doesn't completely hold because the basic
functionality of git is pretty easy to use (especially with gui tools).

------
mrmondo
Just my IMO - takes a bit to learn the basics but it's good enough, move on to
more important problems such as privacy, security etc...

------
Sir_Cmpwn
The "problem" with git, imo, is that it's designed for hackers more so than
professionals. Most people simply don't grok that. As someone with a
background in Linux (for which it was designed, not the trendy "hacker" OSes
like OS X), as someone who's willing to dig in and understand the internals, I
find it beautiful. If I made a VCS from scratch it would end up being pretty
similar to git.

~~~
matt4077
The problem with so-called "professionals" is that they sometimes, when their
egos are running a bit dry, they feel the need to dismiss others as "hackers"
or "hobbyists" or "amateurs" or "hipsters".

It's mostly a problem for them though, because it makes them an easy mark. You
can get them to spend a significant chunk of their time on earth patching
kernels to get their ethernet cards working, and they'll gladly do it and feel
really quite manly and professional and not lonely at all, no.

~~~
Sir_Cmpwn
I'm not dismissing anyone in the way you think. I'm not passing negative
judgement on the people I'm talking about - I just don't think they're
hackers. I don't think they couldn't become them, either. What I'm saying is
this: git is easier to understand with the context you have from being the
kind of hacker I'm talking about. People only ever written rails or node from
the comfort of Atom and their four favorite shell commands simply don't have
the experience to easily understand why git works the way it does. That's not
an inherently bad thing, but it does make git more difficult to understand.

------
Ericson2314
From a very quick read, yet another UI takedown without mention of underlying
content-adressable arch.

As it turns out I do think both the porcelain and plumbing commands both suck,
but I rather read a takedown by somebody who's learned all the layers.

~~~
develop7
> _yet another UI takedown without mention of underlying content-adressable
> arch_

I'm wondering how nice architecture under the hood can be an excuse to have an
Boeing-747-cockpit-style UI?

------
meira
I suggest using a more commercial tool, like Microsoft Visual Source Safe.
There is nothing wrong with Git (at least not at conceptual design level, or
it would not have become one of most successful piece of software of all times
- like top3, alongside with Linux, another masterpiece of the same creator).

~~~
j_s
_Microsoft Visual Source Safe_

Maybe Perforce or something, but recommending VSS in 2016? Hope it works out
for you!

[http://www.highprogrammer.com/alan/windev/sourcesafe.html](http://www.highprogrammer.com/alan/windev/sourcesafe.html)

------
marcv81
TL;DR: author blames his lack of understanding of the git concepts rather than
the git concepts themselves.

~~~
pcwalton
The author clearly understands the git concepts.

~~~
gcp
Most git users commenting on the other hand seem unable to grasp that partial
commits and staging areas are different concepts.

