
Things I hate about Git (2012) - rbanffy
https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/
======
sigsergv
Once you get the essence of git (objects, graph, commits as snapshots etc)
everything becomes really easy. You don't need to memorize all command just
need to understand some basic concepts.

And some points about the article. Git is a framework actually, you need some
workflow to use it in a team. So git _requires_ a lot of discipline from all
team members. You can't just "commit" as in subversion, you _must_ understand
what are you doing. So you can't directly compare git with something like
subversion. And git ≠ github.

Some points are valid: bad and unclear documentation, no "included" workflows,
bad command line UI. Author also didn't mention authorship issues, it's a real
pain.

~~~
wodenokoto
Any recommendations for resources on workflows for GIT?

I mostly write ML code as a single author and there's a lot of experimenting
going on, so often I sit at the end of the day and write a commit message
along the lines of "dicking around" or "updated some files" and feel like I
might as well just sync my stuff with Dropbox and not have to worry about all
the GIT commands.

~~~
BerislavLopac
This is possible the best overview of a number of tried and tested workflows:
[https://about.gitlab.com/2014/09/29/gitlab-
flow/](https://about.gitlab.com/2014/09/29/gitlab-flow/)

They're naturally recommending the GitLab Flow, but a good approach is to read
through it and choose what might work for you. The important thing is to keep
in mind that there are countless variables that will likely be different for
each team -- team size, release schedule, build process, testing etc -- which
mean that each team's flow will be somewhat specific.

And as for commit messages, I have developed a system which helps me write
more meaningful messages with just a little bit of discipline: instead of
summarising what I did, I try to figure how would I give instructions to
someone to do the same. So I have things like "refactor MyBigFunction to
individual methods" or "change SomeSetting to use float instead of int" or
"implement NewClass".

------
justinjlynn
"it's complicated": yes,it is. it's a product designed and built for people
who deal with complex systems and information models on a daily basis; they're
the equivalent of a professional pilot... not your feeble, senile grandmother.
You wouldn't buy your feeble senile grandmother a 787, chuck her in with no
training and simple expect her to fly to Bali, would you?

"I don't like it and here's a heap of examples which lead me to arrive at my
preordained conclusion that it's completely broken": cool, you've found
issues. If you can, fix them and share. If you can't or won't... well, there
are other tools for doing version control and perhaps another might suit you
better. If you have to work with people that use git, I'm sure there's some
way you can generate patch sets and still get stuff done.

~~~
paulddraper
There are two categories of possible criticisms: the model, and the
implementation.

Fixing the implementation means changing code, improving APIs (e.g.
local/remote branch delete).

Fixing the model means finding an everything different system. Yes, a graph-
based VCS more complicated than a linear one. But it also matches realities of
collaborative software development. And reality is complicated.

As you might guess, I'm sympathetic to criticisms of inconsistency or
unnecessary effort, but I believe Git (and other DCVS) to have the completely
correct idea about collaborative text versioning.

~~~
dispose13432
My problem is not the theory. That's easy to learn.

My problem is implementation.

~~~
paulddraper
Ah, the easy one then.

Which DVCS implementation do you like the most?

------
bluepnume
The thing that gets me every time is the git sub-commands which have multiple
orthogonal uses, without so much as a command line flag to differentiate them.

    
    
        git reset abc  # unstage file `abc`
        git reset xyz  # switch to commit `xyz`
    

or:

    
    
        git checkout mybranch  # switch to branch `mybranch`
        git checkout myfile    # remove any local changes to `myfile` since the last commit
    

\---

Maybe this would work great in a typed language where I might have `reset(File
x)` and `reset(Commit x)` with different signatures... but for a CLI where
everything is stringly-typed? Not so fun.

Also, god knows what happens here if there's a branch name with the same name
as a file...

~~~
tylorr
Many command line tools have this problem, that's why the -- operator exists.

------
greydius
I'm not anywhere near an expert with git, but I'm proficient enough to use it
effectively with my normal workflow. I like git, but admittedly the bar was
set really low by subversion.

This article raises some valid points, though. One that resonates most with me
is that git exposes its entire model. I really wish there was a git-lite that
just had the few basic commands that junior developers can grok and not fuck
up so I wouldn't have to waste my time explaining the same stuff for the
umpteenth time.

~~~
nercht12
If you want a straight-forward mental model that works with git, try Gitless.
Note, you will end up learning some new commands that simplify things, and
you'll have to re-learn git if you work for someone that wants you to use the
nitty-gritty, but every convenience has it's downside, and you just have to
weigh that against the immediate benefits.

Edit: Thanks to lyall for the links. He posted below. [1]:
[http://gitless.com/](http://gitless.com/) [2]:
[https://people.csail.mit.edu/sperezde/oopsla16.pdf](https://people.csail.mit.edu/sperezde/oopsla16.pdf)

------
kstenerud
Linus is not a UX guy, and it shows.

~~~
ubernostrum
However, he and many git users enamored of his style are perfectly willing to
be condescending to anyone who points out the problems. Which itself is a
problem.

~~~
wqweto
Is hg easier to use? Or any other DVCS not created by such a bad UX
practitioner?

~~~
jbronn
I was a major user of hg from 2007-2012, before I succumbed to network
effects. The UX of hg was more intuitive for users coming from SVN and CVS.

~~~
bblough
> The UX of hg was more intuitive for users coming from SVN and CVS

I second this. Trying to go from SVN to git left me confused and frustrated,
while I found it much easier to switch to hg. Once I had been using hg for a
while, I found that I had absorbed enough of the difficult/confusing stuff
that switching to git was relatively painless.

------
lyall
It's been discussed on HN before, but gitless[1] is worth checking out.
They've taken a structured approach[2] to finding git's most confusing UX
"idiosyncrasies" and tried to address them. As a user of regular old git I
can't personally speak to how successful they've actually been but it's
interesting nonetheless.

[1]: [http://gitless.com/](http://gitless.com/)

[2]:
[https://people.csail.mit.edu/sperezde/oopsla16.pdf](https://people.csail.mit.edu/sperezde/oopsla16.pdf)

------
ivan_ah
Git is pretty difficult to learn, but the customizations it allows are
amazing.

To get a "fancy oneline log" output, add the following to your `~/.gitconfig`

    
    
        [alias]
            ll = log --graph --oneline  --decorate --date=short --all --pretty=format:'%ad %h %Cgreen%an %Cred%d %Creset%s'
    

then run

    
    
        git ll
    

It's great when rebasing your way out of spaghetti-commitlog situations.

~~~
auscompgeek
I believe --oneline and --decorate (and possibly --date=short as well) are
redundant when specified with --pretty=format.

I personally have this in my ~/.config/git/config:

    
    
        [alias]
            lg = log --graph --pretty=format:'%C(auto)%h%d %s %Cgreen(%ar) %C(bold blue)<%an>%Creset'

------
goerz
All fair points. So what can we actually do about it?

~~~
thunderbong
Use something better? Like Fossil?

I find Fossil way, way more friendly and useful for individual users and
teams.

[http://fossil-scm.org/](http://fossil-scm.org/)

~~~
goerz
Well, I meant how do we actually make _git_ better? It has become and absolute
standard and is not going away anytime soon. Everyone knows it, and there's a
huge ecosystem around it (last but not least Github). I actually think there's
a lot of benefit to that kind of standardization. Personally, I actually like
git, but that doesn't mean it can't or shouldn't be improved. I don't see
switching to some relatively obscure alternative (or even to mercurial) as a
satisfying solution. Of course, anybody who wants to do it should feel free,
but that limits your possibilities for collaboration with the community at
large.

------
luckydude
Git was inspired by BitKeeper, which is now open source. If you want the power
of git without all the crappy UI, check out BK.

www.bitkeeper.org

------
anilgulecha
I think git was written to be distributed, hence merge being a front-and-
center feature, but it is used as with a centralized repo (github/gitlab).

This leads to the UX that was initially planned becoming unwieldy. I think
most organizations default to no-merge, rebase-and-commit-only mode, with
master acting as the central branch to push to.

Hence what git needs to improve it's UX to a newcomer is to help define a
repository to be in a "no-merge", and then help translate user's following
actions:

git init

<make changes>

git commitchanges

<this lists current changes, and tracked, untracked files, and asks which are
to be commited, and makes the commit>

git push

<pushed changes to origin .. automatically rebases, and prompts the user for
any conflicts>

git pull

<pulls changes, automatically rebases, and prompts for any conflicts>

I'm convinced the entire workflow related to merges, and non-centralized
features are what cause UX confusion for a new user.

------
ebbv
A lot of these complaints seem based on the fact that Git has features SVN
doesn't and those features add complexity. Git really isn't that hard to
learn. The trick is to take your time. If you try contributing to projects
with complicated repos before you have a grasp on all the complexities, then
yeah you're gonna have a bad time.

I could write a similar article about how FTP is so much easier to use than
SVN and it would be equally silly.

That is not to say that Git isn't inconsistent and the docs are terrible, but
there are good tutorials out there. If I were more helpful I'd have a link to
one here but I'm on my phone.

------
NumberSix
The primary goal of software development is to solve problems, not to perform
elaborate rituals with version control systems or other tools (IDE's,
Makefiles, etc.).

The primary function of a version control system is to recover earlier
versions of the software in rare error situations where it is hard to figure
out what has gone wrong. Backup to something that worked and identify the
change that caused the problem.

For most software developers, a version control system should appear very
simple so they can focus on solving the end user or customer or their own
problem.

check-in <file | folder> o if the file is new for the project, the VCS should
ask do you want to add this to the project? o check-in <folder> checks
everything in the folder (directory) all at once. If the folder is new: do you
want to add this folder to the project?

checkout <file | folder | project> [ <version> ] o checkout <file> checks out
the most recent version of the file <file>. o checkout <folder> checks out the
most recent versions of the files in <folder> and its sub-folders o checkout
<project> checks out the most recent version of the entire project. The
project can just be the specification of the top level folder! o <version> is
an easy, human readable/understandable specification of the earlier version, a
file sequence number such as 1.43, a folder or module sequence number, or an
overall project sequence number (all generated automatically by the VCS -- at
least by default).

    
    
        All sorts of pain and suffering is avoided by dividing the project into folders for different components and contributors and/or teams.  These check-in/check-out their folder independently.
    

The VCS should be very simple and take care of everything, such as maintaining
a sequential overall project number as well as file sequence numbers,
automatically behind the scenes.

For a single developer or a team in the same office or building or for that
matter office park with a fast network, that is all you need. For remote
collaboration -- such as China and USA -- then you might need one or two
command to push/pull the code to remote repositories; this too should be
simple!

KISS (Keep It Simple Stupid)

------
labrador
I'm working with a small team that uses CVS and I'm I'm in charge of
recommending more modern version control software. I've been learning git
since it seems to be the new standard, but after reading this, I don't think
we have the time it will take to learn it. Is there another open source vcs
that would be a more natural upgrade to CVS?

~~~
lpr22
Specifically for the requirement "Is there another open source vcs that would
be a more natural upgrade to CVS": the answer is hands down Subversion for
that requirement. If you want distributed or "more modern" but not git,
perhaps Mercurial or Bazaar, but they're less prevalent choices.

~~~
labrador
Thank you! Subversion does seem like a great fit. Mercurial seems like it
might be easier to use (Facebook uses their own customized version [1]), but
we don't need distributed at this time.

[1] [https://changelog.com/posts/facebook-mercurial-
git](https://changelog.com/posts/facebook-mercurial-git)

------
angry-hacker
I started using git as a hobbyst with the help of smartgit. It somehow made me
realize what is git all about the 200x better than any tutorial. I use command
line too, but things like diffing, adding files etc. it just makes life
easier. Seriously you're a masochist if you don t use it. It'd free for
personal use!

------
LouisSayers
A thought: if you think you can make git better, why not just write a DSL
(domain specific language) on top of it?

I mean, it already does everything under the sun, so there's a challenge for
anyone up for it!

~~~
LouisSayers
Even better - write a chat bot for git hahaha :D make it so it can help you
get out of tricky situations and not have search stackoverflow all the time

------
rileymat2
I have not had this problem recently because moved from Windows to Mac, but at
some point about 8 years ago was the way git handled windows line endings was
truly maddening.

~~~
chj
To this day I never understand how to handle line endings correctly. I mean,
when I have issues, I would need to google, and then forget again. Fortunately
I don't have to work on windows that much.

------
Dylan16807
It's weird to see an exclamation point after "detached head state". Checking
out a specific commit is easy to do in SVN too.

------
kevin_thibedeau
Considering that svn is a half implemented VCS where everything is a branch
but merging is a royal PITA I'll take Git's warts.

~~~
lisivka
Yeah, at Bazaarvoice we invented our own tool to keep information about
branches for simple rebase and merge of feature branches.

------
iamwil
"In the beginning, all you want are results. In the end, all you want is
control."

------
Animats
The crucial criticism:

 _The fundamental promise of any version control system is this: “Once you put
your precious source code in here, it’s safe. You can make any changes you
like, and you can always get it back”. Git breaks this promise. Several ways a
committer can irrevocably destroy the contents of a repository:_

    
    
        git add . / … / git push -f origin master
        git push origin +master
        git rebase -i <some commit that has already been 
           pushed and worked from> / git push
    

That should not be possible.

Mandatory XKCD: [1]

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

~~~
jjoonathan
A previous criticism was that you had to know about a set of things including
the reflog in order to use git. The reflog is one of several ways to undo the
"irrevocable destruction" above. Complaining about both issues feels like
double-dipping :)

Also, I suspect that many of the "hosted git" implementations out there
prevent this from happening by default. I know that both of the ones I use in
my day job (gitlab and bitbucket) do, but I'm not 100% certain it's a default
as opposed to something our ops guys did. In any case, far from impossible.
EDIT: see boaardwalk's post.

Also, svn won't protect you from `rm -rf /` on the server, while git will,
which is pretty cool.

------
arunc
Git CLI, aka designed in hell!!

------
taspeotis

        Things I hate about Git (stevebennett.me)
        31 points by rbanffy 2 hours ago
    

Could do with 2012 in the title:

    
    
        Posted by steveko on February 24, 2012

~~~
dang
Yes. Added.

------
scotty79
I'd like git to be aware of the grammar of the files it's diffing and merging.

It could use neural network for this for all I care. Anything but merging
lines as if they contained completely meaningless string of characters.

~~~
scotty79
Hi. Thanks for downvote. Although pointing me to some smart mergetool would be
even more appreciated.

------
relics443
I've been using git for 7 years now. Never used anything else for version
control (besides visual source safe which I try to forget).

Never felt the need or desire to try anything else.

~~~
relics443
Genuinely curious as to why I'm getting down voted without explanation for
stating my opinion.

~~~
rbanffy
I'd not downvote your comment but I'd like to point out you have a biased
perception. You clearly state you never used anything else and then you say
you never felt the need to use anything else.

It's not unlike a programmer who only knows GWBASIC saying they feel no need
for recursion because they never wrote any code that relied on it, or named
functions, because subroutines can do that. Or a C programmer who thinks
class-based inheritance is superfluous syntactic sugar.

I don't mean it as an offense, mind you, but your lack of experience in DVCSs
makes your opinion suspect. Spend a month actually working with Bzr or
Mercurial and then, having been exposed to different solutions to the same
problem, your opinions will be much richer.

~~~
relics443
My point wasn't that the others weren't good. It was that git has always met
all my requirements and I never ran into any issues that made me want to try
another solution.

