Die Git Die

I'm not trying to argue that git is divinely inspired or whatever— this is confusing behavior.<p><i>It tells me I can lose history, but this is a revision control system, surely they don't mean I can actually lose history?</i><p>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?

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.<p>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)<p>So this basically amounts to a blog post complaining that git is hard.

"The git, the?"<p>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!

I totally agree that this is surprising behavior. But git did try to tell you:<p><pre><code> ! [rejected] master -&#62; master (non-fast-forward) </code></pre> And once you've invoked the gods of `push -f`, you're on your own.

&#62; However, git will not <i>pull</i> matching branches. That means that all your branches except your current branch will not get updated when you pull.<p>&#62; Of course, a less good but at least sane behavior would have been if pull also pulled matching branches by default<p>I don't see any way this could work in the face of potentially having merge conflicts in non-current branches.

&#62; However, git will not pull matching branches. That means that all your branches except your current branch will not get updated when you pull.<p>This is why git-up was created: <a href="https://github.com/aanand/git-up" rel="nofollow">https://github.com/aanand/git-up</a><p>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.

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.<p>But don't get me wrong. On the whole, git is fantastic and a real improvement on its predecessors.

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.<p><pre><code> git fetch &#60;remote&#62; &#60;branchname&#62;:refs/remotes/&#60;remote&#62;/&#60;branchname&#62; git rebase &#60;branchname&#62; &#60;remote&#62;/&#60;branchname&#62;</code></pre>

Well. Actually you are using git in place where svn or rsync should be enough.<p>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.<p>So are using it as tape archiver and wondering why defaults look so unfrendly.

I am so glad someone wrote this up and shares my frustration.<p>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)/

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.

You can't blame git where you clearly didn't fully understand how it works, and you <i>clearly</i> 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 :)

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:<p>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`.<p>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.<p>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):<p><pre><code> $ 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 -&#62; pages ! [rejected] master -&#62; 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.</code></pre>

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

EasyGit (<a href="http://people.gnome.org/~newren/eg/" rel="nofollow">http://people.gnome.org/~newren/eg/</a>) 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.<p>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`.

Code section 3: why create a new clone of the repo when all he needed was to create a new branch and modify that?<p>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<p><pre><code> cd ../die-git-die.pages </code></pre> 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?

<i>&#62; $ git push origin gh-pages</i><p>I think that if you had changed the above to<p><pre><code> $ git push -u origin gh-pages </code></pre> then everything else would have gone smoothly.

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.

Anyone use <a href="http://www.git-legit.org" rel="nofollow">http://www.git-legit.org</a> ?<p>Looks like it was inspired by a hackernews comment <a href="https://news.ycombinator.com/item?id=2684483" rel="nofollow">https://news.ycombinator.com/item?id=2684483</a> and it replaces these commands

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.

you need to read "Git for dummies"

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.<p>Github is the one who wants you to use git. This is why github built you a gui.

<p><pre><code> man gittutorial</code></pre>

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