Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I hate about Git (2012)

stevebennett.me

Post reply on HN
Print view View original

11–20 of 83 posts

Re: Things I hate about Git (2012)

#12

Post by 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  / git push
That should not be possible.

Mandatory XKCD: [1]

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

Re: Things I hate about Git (2012)

#14

Post by ivansavz »

wqweto wrote: post #4
ubernostrum wrote: post #3

Earlier quoted context omitted.

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.

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

I've used both extensively and I think they're virtually identical. Mercurial is a bit nicer because it's written in Python, but git has github going for it.

In my experience, once you get into more complicated commands like rebase, I had to read a lot of docs to get things to work in both systems, so I'd say hg is easier to get started with but they're on par overall in terms of complexity.

As a sidenote, I think the ability to `rebase -i` work branches and squash, edit, and drop changesets is a very useful feature, and it's made very easy in git. Mercurial can rebase branches, but it really doesn't like it...

Re: Things I hate about Git (2012)

#17

Post by downer72 » 

  The man pages are one almighty “fuck you”.
And there are people I've wanted to strangle for telling me: RTFM.

The examples in this article are the crowning example of why their painful death would be well-deserved.

There's this thing about bedside manner that technically adept people need to cultivate, just as doctors do.

Did I mention I despise cold, snotty doctors too?

There's nothing worse than a condescending prick doctor wielding authority against you, when your sick or need medication and just trying to find help. The doctors that do this, know that they can cast a long shadow by dropping hints that they aren't on your side.

It's kind of the same scenario, and I try to remember how I've felt as a patient, when people ask me for help. You can usually grasp what people are really after, when their trying to figure something out, and ask for even a hint in the right direction.

It's the mark of rotten bastard that won't give even the slightest helping hand to someone who's on the same team. Pure evil, when you've helped someone with simple questions, and they sneer at you, given the chance to reciprocate.

Example: This one piece of shit sees a co-worker and I struggling with some retarded group policy problem on a windows machine. My co-worker is slightly clueless, but that's okay because he's not a fucking asshole. POS intervenes, starts driving on clueless co-workers machine, pops open mmc.exe twiddles a setting, and fixes the thing. I need to do the same thing. I ask him, so what was the fix?

  Google is your friend.
I have sworn a blood oath to myself that before I die, I must slaughter this man's progeny, and proclaim his seed wiped from the earth, before caving in his skull with a tomahawk, eating his heart raw, and adorning my breech clout with his scalp.

Re: Things I hate about Git (2012)

#18

Post by ivansavz »

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.

Re: Things I hate about Git (2012)

#19

Post by jjoonathan »

Animats wrote: post #12

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 / git push That should…

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.

Re: Things I hate about Git (2012)

#20

Post by greggman »

ubernostrum wrote: post #10
wqweto wrote: post #4

Earlier quoted context omitted.

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

hg's command-line interface is far better organized, yes, at least in the sense that it appears to have been organized rather than organically slapped together and papered over with "well it'd make sense if only you understood more about it". Blaming users for not understanding a bad interface is one of the classic mistakes.

hg's original workflow didn't encourage git style branches at all nor did it have any kind of stage IIRC. They've since been optionally added. Is that workflow in hg more intuitive or is only its far less powerful original workflow more intuitive?

It took me a while make the mental jump from svn style branches to git style and from no stage to having a stage but I'd never want to go back now that I understand them.

Post reply on HN