Die Git Die

by reinhardt • 13 years ago

35 94 13 years ago

verelo• 13 years ago

I am so glad someone wrote this up and shares my frustration.

I've been through this exact battle so many times, git pull should only ask you for your branch if you've told it you want it to (as a safety measure i guess)/

abimaelmartell2• 13 years ago

you need to read "Git for dummies"

kansface2• 13 years ago

git has no user interface. git expects its users to have an in depth understanding of its implementation details. These are failures of git. Ideally, studying abstruse man pages to avert disaster wouldn't be required of new users.

abimaelmartell2• 13 years ago

i been using git for almost two years, never needed a gui

jhaglund2• 13 years ago

Git doesn't have much of a user interface because it's target is developers who want to use the command line. Git is confusing until it's not, and then it's awesome.

It's kinda like you're using wget to surf the web, and complaining that it doesn't have a GUI.

http://git-scm.com/downloads/guis

kh_hk• 13 years ago

You are confusing 'implementation details' with how does git abstract reality. You are not supposed to know how things are implemented, really.

Rarebox2• 13 years ago

Git interface is hard, because git is hard. Git is hard because it is so powerful. Git developers don't care about newbie users who can't even bother to RTFM. There is just no reason they should.

Git user interface is fine when you finally learn how to use git.

egonschiele2• 13 years ago

I totally agree that this is surprising behavior. But git did try to tell you:

    ! [rejected]        master -> master (non-fast-forward)

And once you've invoked the gods of `push -f`, you're on your own.

monstrado• 13 years ago

An evil prank would be to change someone's 'git push' alias to use -f by default.

morsch• 13 years ago

As someone who's only used git in fairly straightforward ways, that line is complete gibberish to me.

egonschiele2• 13 years ago

It's saying you tried to push the master branch (`master -> master`) and it was `rejected`. Since he made a bunch of changes to the master branch from another dir, of course his changes are not going to get pushed.

lennartregebro10• 13 years ago

Sure, which is why I made a backup first. I didn't lose any data. I'm just ranting about what is some of the bad things with git.

nessus425• 13 years ago

> $ git push origin gh-pages

I think that if you had changed the above to

    $ git push -u origin gh-pages

then everything else would have gone smoothly.

kansface2• 13 years ago

This is what I do personally. We also use rebases liberally at my office which requires us to force push upstream. On-boarding new team members scares the shit out of me.

encoderer• 13 years ago

I hear ya, but as you obv know as long as you're pushing to a location only you are pushing to, a force-push is harmless.

Moreover, any loss that does occur is recoverable as long as you keep your clone around. Git doesn't garbage collect refs for at least 30 days. So you're pretty protected if you clone to a location that has regular backups.

lennartregebro10• 13 years ago

That's interesting, and maybe I'll try that in the future. But just as with the "matching" vs "current" why is the default here the thing that is guaranteed to cause problems, instead of what people expect?

My point is not that git is impossible to use. It's that the way git behaves by default is insane.

nessus425• 13 years ago

The default probably only seems insane to us because we don't grok whatever workflow Linus was using with Git when he came up with the defaults. The defaults probably make a lot of sense for his workflow.

A common mistake people make when bitching about Git, is assuming that their workflow is the only workflow. Git supports a multitude of different workflows, and that fact is both a strength and a weakness.

jrockway3• 13 years ago

"The git, the?"

But seriously, yes, you have to learn how to use Git in order to use Git. But you don't have to use Git. Click here to renew your Visual Source Safe license, or better, just copy your file to file.1 every time you edit it. No way that can go wrong!

kennymeyers• 13 years ago

I understand Hacker News is a place for "serious" discussion, but a good Simpsons' reference always deserves props.

jrockway3• 13 years ago

No one who writes a version control rant could be an evil man.

stormbrew5• 13 years ago

You say that, but the next version of Visual Studio's gonna have git built in. Seriously. Gonna be a lot of new (and probably confused) users out there.

spo81rty• 13 years ago

But VS won't require using command line

ryanknapp• 13 years ago

It's already pretty close to being there; you only need to install a plugin now in order to get first class support in the IDE [0]. A few days ago, you would have had to install the VS2012 Update 2 CTP (hard to justify in a corporate environment in case bugs slow development), but now that it has gone RTM, there isn't much a barrier to entry besides awareness that the plugin exists.

[0] http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-...

ph0rque• 13 years ago

"The git, the?"

And feminine, at that?

endlessvoid94• 13 years ago

I don't know why, but I always end up telling every single person who either 1) Bitches about git, or 2) asks for help, that I always, always, always tell "git push" or "git pull" which remote and branch.

It's muscle memory and makes everything more explicit and easy to understand. Although, in this case, it sounds like you expect git to be intuitive. (Which it is not)

So this basically amounts to a blog post complaining that git is hard.

barumrho• 13 years ago

From my experience, git pull origin branch didn't do what I expected. (Pulling from the remote branch to the current branch.) I haven't figured out what it does, so I just use git fetch then merge. :(

glitchdout• 13 years ago

Git pull does a git fetch of the branch specified and then does a git merge into the current branch.

kstenerud• 13 years ago

It's a problem of user interface design. Git's user-machine interface does not follow the principle of least astonishment. It's not orthogonal. Functionality is grouped in very strange ways (you list, move, rename and delete branches with branch, but create branches using checkout? Seriously???).

And don't even get me started on the nightmare that is submodules.

The whole thing reminds me of the bad old unix days of "if it was hard to write, it should be hard to understand."

damncabbage• 13 years ago

you list, move, rename and delete branches with branch, but create branches using checkout? Seriously???

  git checkout -b new-branch

... is a shortcut for:

  git branch new-branch
  git checkout new-branch

You can create the branch or otherwise manipulate it without actually checking it out, so it's useful to have it separate and have a shortcut.

(I agree that git's interface is terrible, but I disagree that this is one of those cases. :) )

wonderzombie• 13 years ago

I'm not trying to argue that git is divinely inspired or whatever— this is confusing behavior.

It tells me I can lose history, but this is a revision control system, surely they don't mean I can actually lose history?

Sorry, but why did you think that they said that except to tell you that you could actually lose history? You ignored the rest of the error message and used --force. And then you were surprised that what the error message told you actually came to pass?

saurik3• 13 years ago

While reading that line from the article I thought of a sign that says not to put a child safety seat in front of an airbag, along with the carefully rendered diagram of the airbag breaking the top of the safety seat off and striking the child in the head, and someone thinking "but these are safety restraint systems; surely they don't mean that they could actually harm the passenger?" and then going ahead with the incorrect safety seat placement without deactivating the airbag.

lennartregebro10• 13 years ago

No the message is rather: "If you press this button, the engine will vanish", and when you then look under the hood, it turns out the car never had an engine, it was a little dwarf pedalling and making engine noises. I think you may agree this is pretty surprising considering it's the brand of car that is currently winning the car wars.

pifflesnort• 13 years ago

It still is a broken design that you can ever lose history or hose a repository in a tool that is designed to store history, forever.

That's a sharp edge that should be exposed, and its not the only one in git.

stormbrew5• 13 years ago

To be fair, I don't think even in the scenario in question the history is truly lost. It'll still be in the reflog at least.

jrdn• 13 years ago

I really, really want to be able to lose some history sometimes. Like if someone checks in sensitive user data by accident. Rolling it back is insufficient, I want that expunged. Maybe git doesn't do it perfectly, but it has reason to do it.

cjh_5• 13 years ago

Most of the time the information is not lost, and if you act quickly, it often just takes some git-reflog-foo to wrestle it out (or possibly as simple as looking at ORIG_HEAD, depending on how you 'lost' it).

History not referenced will eventually be reaped by the garbage collector though.

knowtheory• 13 years ago

You are making a mistake regarding how you think about git.

Git is not really a revision tracking system.

Git is a content tracking file system manager. It happens to be the case that these two uses largely overlap, but what Git really lets you do is take snapshots of your filesystem, annotate each snap shot, and allow you to compare snapshots.

It does not keep track of your changes. You keep track of your changes when you use git by annotating each snapshot.

jrockway3• 13 years ago

Wait until you see what happens when you type "rm -rf .git". Oh noes, the rm tool lets me DELETE HISTORY!

lennartregebro10• 13 years ago

A revision control system that can lose history is a fundamentally flawed revision control system. (Note that lose history is not the same as explicitly delete certain revisions). The error message is basically saying "Please remember that git isn't really a revision control system", which I found a very surprising and hard to believe statement. Turned out it was true. This is one of the major problems with git, and why it should die.

syncerr2• 13 years ago

Whenever I'm pulling down code, instead of `git pull', I use fetch. I fetch the specific branch into the local remote tracking branch (remote/branchname). Then use rebase, rather than merge. I won't lose anything and it avoids those dumb merge commits. Also, aliases are great for this.

    git fetch <remote> <branchname>:refs/remotes/<remote>/<branchname>
    git rebase <branchname> <remote>/<branchname>

kemayo• 13 years ago

That's equivalent to just doing `git pull --rebase`, no?

syncerr2• 13 years ago

`git pull --rebase` does not update my remote tracking branch. Though you may not care about this.

tingletech3• 13 years ago

I never knew of the local remote tracking branches in git until now. I just went and looked it up and found this post that explains it more http://longair.net/blog/2009/04/16/git-fetch-and-merge/

  git branch -r

will show all the remote tracking branches I had no idea existed. Thanks a lot, git makes much more sense to me now.

eridius• 13 years ago

This just seems like yet another case of someone who thinks he's too smart to read the manual. RTFM exists for a reason.

Shamharoth• 13 years ago

  man gittutorial

stormbrew5• 13 years ago

Git has a lot of UI problems. This is not really surprising. It's gotten a lot better, but I do think that no matter how proud Torvalds is of the fact that he never looked at another version control system for inspiration, a lot of pain could have been avoided if he had (even while still going in the different directions he did). Not all of us had the 'luxury' of never working with version control before.

But don't get me wrong. On the whole, git is fantastic and a real improvement on its predecessors.

sjwright3• 13 years ago

Git is a brilliant piece of technology engineering, with an embarrassingly half-baked user interaction model.

If I could change one thing, it would be pushing and pulling between workstations and central repositories. Distributed is nice, but at the end of the day you still want your code to end up somewhere, and Git doesn't make that process feel smooth or robust.

glurgh2• 13 years ago

  >no matter how proud Torvalds is of the fact that he
  >never looked at another version control system for
  >inspiration

What gave you that impression? Git was strongly influenced by BitKeeper and to a much lesser extent by Monotone. And, arguably, 'anti-inspired' by several other VCS's Linus would have surely been at least passingly familiar with.

stormbrew5• 13 years ago

There's a rather famous video of him talking about how wonderful his lack of experience with traditional VCS' was for producing git. Obviously he had used bitkeeper (but wasn't very fond of it), and he was probably exaggerating a bit even after that.

I think most of the outside influence came from people who weren't Torvalds, but the command set is just so weirdly different from every other VCS (even where functionality maps nearly 1:1) that it seems likely that it was designed without much consideration for existing use patterns of other VCS'.

defen• 13 years ago

> However, git will not pull matching branches. That means that all your branches except your current branch will not get updated when you pull.

> Of course, a less good but at least sane behavior would have been if pull also pulled matching branches by default

I don't see any way this could work in the face of potentially having merge conflicts in non-current branches.

cjh_5• 13 years ago

This is the reason pulling all matching branches (and pushing all matching branches) by default is generally a bad idea.

zllak• 13 years ago

You can't blame git where you clearly didn't fully understand how it works, and you clearly ignored its error messages, and used the -f option. There's some very useful tools like "tig" to check the state before pushing. A good rule of thumb is to never push -f before being absolutely sure of what it's going to do. And everything is not lost, you can still use "git reflog" to retrieve the previous state. You're whining about git where you are clearly in fault here :)

trotsky• 13 years ago

git was designed by and for people who read man pages. the fact that it has significant usability problems is a problem for them only in so far as they are interested in having you contribute code to them, which is to say very little.

Github is the one who wants you to use git. This is why github built you a gui.

Legion• 13 years ago

> However, git will not pull matching branches. That means that all your branches except your current branch will not get updated when you pull.

This is why git-up was created: https://github.com/aanand/git-up

It's silly that this is necessary, but "gem install git-up" and then run "git up" instead of "git pull" and you'll be much happier.

Cryode• 13 years ago

I'm grateful for the Tower GUI app. Just wish it would tell me what commands it was using, since I'd like to know.

Muromec2• 13 years ago

Well. Actually you are using git in place where svn or rsync should be enough.

Just look at git.kernel.org - over 400 repos only for linux kernel. This is what git designed for - to be Mass Distributed Version Control System.

So are using it as tape archiver and wondering why defaults look so unfrendly.

bumeye2• 13 years ago

You make it sound like git is unsuitable for this, i disagree. I often use git for one-man projects, both with and without an external repository. Once you learn how to use it it works great. I would never want to return to svn/rsync/zip-files.

Muromec2• 13 years ago

>You make it sound like git is unsuitable for this, i disagree

It's not me, it's post author who makes it sound so. Actually it's up to user to decide what is suitable for him and what is not.

ams6110• 13 years ago

s/git/hg/ and get on with life.

harshreality• 13 years ago

Code section 3: why create a new clone of the repo when all he needed was to create a new branch and modify that?

Code section 5 and 6 are apparently modifying the code branch, and the pages branch, respectively, but doing so in separate local clones of the repo. I think there's a typo in code section 6, where I think he meant to start with

  cd ../die-git-die.pages

This doesn't seem like a situation where multiple local git repos are needed. What's wrong with managing both branches from one local repo?

bumeye2• 13 years ago

This is the way that github recommends (https://help.github.com/articles/creating-project-pages-manu...).

A separate folder for the gh-pages branch makes sense because this branch has nothing in common with any of the other branches. It doesn't share any code or commits with your master branch.

The repository actually has two base commits and it's like two repositories contained in one. Thus needing two separate folders.

tingletech3• 13 years ago

Anyone use http://www.git-legit.org ?

Looks like it was inspired by a hackernews comment https://news.ycombinator.com/item?id=2684483 and it replaces these commands

roryokane• 13 years ago

EasyGit (http://people.gnome.org/~newren/eg/) fixes this problem. It’s a command-line wrapper for Git that makes some interfaces more usable. `eg push` pushes only the current branch; you must write `eg push --matching-branches` to do what `git push` does.

EasyGit also provides better built-in documentation. For example, if you get merge conflits, `eg status` will mention that you can run `eg help topic middle-of-merge`. That command opens a page explaining your options – how to find conflicts, resolve conflicts, etc. I have found EasyGit very useful, and when it’s installed, I always use `eg` instead of `git`. You can download the EasyGit script at the linked website, or install it using Homebrew with `brew install easy-git`.

178• 13 years ago

He is using a hack to store the GitHub pages. That this is even possible is due to the awesomeness of git. Since it is a hack, you have to be careful what you're doing. He should have done all the gh-pages stuff in a separate clone. The GitHub instructions where he pasted the branch creation commands from also tells you to do just that. Keep the pages branch in a clone of the repo inside the repo, just in a folder called 'docs'. You'll never have to mess with these branches, as you can generate docs, commit and push from a Makefile.

peff• 13 years ago

I notice that he omits the full output of `git push`. A lot of the confusion is caused by the fact that the default push mode is `matching`. I don't know what git version he is running, so I can't say exactly what text was omitted, but I would have expected to see two things:

1. Not only mention of the rejected `master` branch, but also the successful push of the `gh-pages` branch. Which makes it a lot more clear that git is trying to push multiple branches, and that the rejection has to do with `master` and not `gh-pages`.

2. The push default of `matching` is changing soon in upstream git (because it is suitable for certain types of workflow, but can cause confusion, as seen here), and the last several versions complain loudly if you do not set the default. This is intended to call attention to this common pitfall, and to notify users so that they are not surprised by the change when it happens.

With git v1.8.2, here is the full output of `git push` in his situation (you may note that the non-fast-forward advice has been improved, too):

  $ git push
  warning: push.default is unset; its implicit value is changing in
  Git 2.0 from 'matching' to 'simple'. To squelch this message
  and maintain the current behavior after the default changes, use:
  
    git config --global push.default matching
  
  To squelch this message and adopt the new behavior now, use:
  
    git config --global push.default simple
  
  See 'git help config' and search for 'push.default' for further information.
  (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
  'current' instead of 'simple' if you sometimes use older versions of Git)
  
  Counting objects: 8, done.
  Delta compression using up to 8 threads.
  Compressing objects: 100% (2/2), done.
  Writing objects: 100% (6/6), 428 bytes, done.
  Total 6 (delta 0), reused 0 (delta 0)
  To /home/peff/foo/die-git-die/parent.git
     148db6f..25cd4ef  pages -> pages
   ! [rejected]        master -> master (fetch first)
  error: failed to push some refs to '/home/peff/foo/die-git-die/parent.git'
  hint: Updates were rejected because the remote contains work that you do
  hint: not have locally. This is usually caused by another repository pushing
  hint: to the same ref. You may want to first merge the remote changes (e.g.,
  hint: 'git pull') before pushing again.
  hint: See the 'Note about fast-forwards' in 'git push --help' for details.

lennartregebro10• 13 years ago

It's nice to know things have improved. Apparently they will also remove the stupid "matching" default on push in version 2. But I think that pull and push still will not do exactly the same in choice what to pull and push even in version 2, as I understand it. Which still is bad.

hemphill• 13 years ago

I've gotten in the habit of always adding the remote and branch name when doing a pull or push. Seems to avoid all these issues.

Die Git Die

Related Stories