6 ms·

Die Git Die

35 points by reinhardt 14y ago

verelo 14y 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)/
abimaelmartell 14y ago
you need to read "Git for dummies"
- kansface 14y 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.
  - abimaelmartell 14y ago
    i been using git for almost two years, never needed a gui
    - deleted 14y ago
      [deleted]
  - jhaglund 14y 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 http://git-scm.com/downloads/guis
    - niggler 14y ago
      GUI != UI parent comment is arguing that the command-line interface is nontrivial, which is a fair criticism. Contrast with 'cp' or 'mv'
      - tingletech 14y ago
        To use wget, I often need to read the manual or look up some notes to get the exact command I want.
      - jhaglund 14y ago
        Well, go right ahead and use cp and mv for your source control! No one (except maybe linus) ever said git is easy. But it is flexible and powerful. Anyway, this whole thing comes down to the user ignoring clear warnings. It seems clear to me that using "force" can break things.
  - kh_hk 14y ago
    You are confusing 'implementation details' with how does git abstract reality. You are not supposed to know how things are implemented, really.
  - Rarebox 14y 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.
    - LeonidasXIV 14y ago
      A browser is hard. Firefox is easy. I don't think your reasoning holds. That's why we have abstractions, to make hard things easy.
      - Rarebox 14y ago
        The idea of a browser is far easier to understand than git from users perspective. Implementation is something user doesn't have to know about (for firefox or git). What makes git so powerful is that it doesn't abstract things as much as other systems. To make git easier would mean making it less powerful. I rather use a tool that is complex than a tool that doesn't let me do what I want.
    - lennartregebro 14y ago
      No, git is not hard because it's powerful. It's hard because it's defaults are non-sensical, and it's user interface are neither close enough to how it's internal mechanics to be predictable, but not far enough from the internal mechanics to provide understandable abstractions. The result is that it behaves unpredictably and confusingly. And that's a bad UI, no matter how powerful things are below. "Git developers don't care about newbie users who can't even bother to RTFM." This is probably true. "There is just no reason they should." Yes there is.
deleted 14y ago
[deleted]
egonschiele 14y 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 14y ago
  An evil prank would be to change someone's 'git push' alias to use -f by default.
- morsch 14y ago
  As someone who's only used git in fairly straightforward ways, that line is complete gibberish to me.
  - egonschiele 14y 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.
- lennartregebro 14y 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.
nessus42 14y 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.
- kansface 14y 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 14y 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.
- lennartregebro 14y 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.
  - nessus42 14y 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.
    - lennartregebro 14y ago
jrockway 14y 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 14y ago
  I understand Hacker News is a place for "serious" discussion, but a good Simpsons' reference always deserves props.
  - jrockway 14y ago
    No one who writes a version control rant could be an evil man.
- stormbrew 14y 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 14y ago
    But VS won't require using command line
    - lucisferre 14y ago
      You'd think that would be a good thing, but I highly doubt it. Visual Studio and .NET in general is not generally known for it's exceptional use of abstractions.
  - ryanknapp 14y 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-40f4-8a5e-d6724bdb980c http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-...
endlessvoid94 14y 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 14y 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 14y ago
    Git pull does a git fetch of the branch specified and then does a git merge into the current branch.
    - deleted 14y ago
      [deleted]
- kstenerud 14y 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."
  - deleted 14y ago
    [deleted]
  - damncabbage 14y ago
wonderzombie 14y 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?
- saurik 14y 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.
  - lennartregebro 14y 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.
    - saurik 14y ago
      I would then counter with "if you redline the engine and throw the car into a low gear, the transmission and the engine may both be damaged or even destroyed". Yes: there are cars (both automatic and manual, as this problem can affect either) where this is mitigated by a bunch of fancy electronics, but that is unlikely to be true of the really powerful cars that are designed under the premise that the driver can be trusted (like git).
      - 14y ago
syncerr 14y 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 14y ago
  That's equivalent to just doing `git pull --rebase`, no?
  - syncerr 14y ago
    `git pull --rebase` does not update my remote tracking branch. Though you may not care about this.
    - __david__ 14y ago
      The "git pull" man page states that "git pull --rebase" is exactly equivalent to "git fetch" followed by "git rebase" so I'm not sure why it wouldn't update your remote tracking branch (since that is what "git fetch" does).
- tingletech 14y 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/ 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 14y 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 14y ago
man gittutorial
stormbrew 14y 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.
- sjwright 14y 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.
- glurgh 14y 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.
  - stormbrew 14y 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'.
    - glurgh 14y ago
defen 14y 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_ 14y ago
  This is the reason pulling all matching branches (and pushing all matching branches) by default is generally a bad idea.
zllak 14y 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 14y 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 14y 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 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 14y 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.
Muromec 14y 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.
- bumeye 14y 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.
  - Muromec 14y 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 14y ago
s/git/hg/ and get on with life.
harshreality 14y 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?
- bumeye 14y ago
  This is the way that github recommends (https://help.github.com/articles/creating-project-pages-manually 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.
tingletech 14y ago
Anyone use http://www.git-legit.org http://www.git-legit.org ? Looks like it was inspired by a hackernews comment https://news.ycombinator.com/item?id=2684483 https://news.ycombinator.com/item?id=2684483 and it replaces these commands
roryokane 14y ago
EasyGit (http://people.gnome.org/~newren/eg/ 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 14y 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 14y 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.
- lennartregebro 14y 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 14y 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.
deleted 14y ago
[deleted]

35 points by reinhardt 14y 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)/

abimaelmartell 14y ago

you need to read "Git for dummies"

kansface 14y 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.
- abimaelmartell 14y ago
  i been using git for almost two years, never needed a gui
  - deleted 14y ago
    [deleted]
- jhaglund 14y 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 http://git-scm.com/downloads/guis
  - niggler 14y ago
    GUI != UI parent comment is arguing that the command-line interface is nontrivial, which is a fair criticism. Contrast with 'cp' or 'mv'
    - tingletech 14y ago
      To use wget, I often need to read the manual or look up some notes to get the exact command I want.
    - jhaglund 14y ago
      Well, go right ahead and use cp and mv for your source control! No one (except maybe linus) ever said git is easy. But it is flexible and powerful. Anyway, this whole thing comes down to the user ignoring clear warnings. It seems clear to me that using "force" can break things.
- kh_hk 14y ago
  You are confusing 'implementation details' with how does git abstract reality. You are not supposed to know how things are implemented, really.
- Rarebox 14y 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.
  - LeonidasXIV 14y ago
    A browser is hard. Firefox is easy. I don't think your reasoning holds. That's why we have abstractions, to make hard things easy.
    - Rarebox 14y ago
      The idea of a browser is far easier to understand than git from users perspective. Implementation is something user doesn't have to know about (for firefox or git). What makes git so powerful is that it doesn't abstract things as much as other systems. To make git easier would mean making it less powerful. I rather use a tool that is complex than a tool that doesn't let me do what I want.
  - lennartregebro 14y ago
    No, git is not hard because it's powerful. It's hard because it's defaults are non-sensical, and it's user interface are neither close enough to how it's internal mechanics to be predictable, but not far enough from the internal mechanics to provide understandable abstractions. The result is that it behaves unpredictably and confusingly. And that's a bad UI, no matter how powerful things are below. "Git developers don't care about newbie users who can't even bother to RTFM." This is probably true. "There is just no reason they should." Yes there is.

deleted 14y ago

[deleted]

egonschiele 14y 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 14y ago
An evil prank would be to change someone's 'git push' alias to use -f by default.
morsch 14y ago
As someone who's only used git in fairly straightforward ways, that line is complete gibberish to me.
- egonschiele 14y 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.
lennartregebro 14y 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.

nessus42 14y 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.

kansface 14y 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 14y 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.
lennartregebro 14y 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.
- nessus42 14y 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.
  - lennartregebro 14y ago

jrockway 14y 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 14y ago
I understand Hacker News is a place for "serious" discussion, but a good Simpsons' reference always deserves props.
- jrockway 14y ago
  No one who writes a version control rant could be an evil man.
stormbrew 14y 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 14y ago
  But VS won't require using command line
  - lucisferre 14y ago
    You'd think that would be a good thing, but I highly doubt it. Visual Studio and .NET in general is not generally known for it's exceptional use of abstractions.
- ryanknapp 14y 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-40f4-8a5e-d6724bdb980c http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-...

endlessvoid94 14y 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 14y 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 14y ago
  Git pull does a git fetch of the branch specified and then does a git merge into the current branch.
  - deleted 14y ago
    [deleted]
kstenerud 14y 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."
- deleted 14y ago
  [deleted]
- damncabbage 14y ago

wonderzombie 14y 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?

saurik 14y 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.
- lennartregebro 14y 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.
  - saurik 14y ago
    I would then counter with "if you redline the engine and throw the car into a low gear, the transmission and the engine may both be damaged or even destroyed". Yes: there are cars (both automatic and manual, as this problem can affect either) where this is mitigated by a bunch of fancy electronics, but that is unlikely to be true of the really powerful cars that are designed under the premise that the driver can be trusted (like git).
    - 14y ago

syncerr 14y 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 14y ago
That's equivalent to just doing `git pull --rebase`, no?
- syncerr 14y ago
  `git pull --rebase` does not update my remote tracking branch. Though you may not care about this.
  - __david__ 14y ago
    The "git pull" man page states that "git pull --rebase" is exactly equivalent to "git fetch" followed by "git rebase" so I'm not sure why it wouldn't update your remote tracking branch (since that is what "git fetch" does).
tingletech 14y 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/ 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 14y 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 14y ago

man gittutorial

stormbrew 14y 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.

sjwright 14y 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.
glurgh 14y 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.
- stormbrew 14y 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'.
  - glurgh 14y ago

defen 14y 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_ 14y ago
This is the reason pulling all matching branches (and pushing all matching branches) by default is generally a bad idea.

zllak 14y 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 14y 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 14y 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 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 14y 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.

Muromec 14y 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.

bumeye 14y 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.
- Muromec 14y 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 14y ago

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

harshreality 14y 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?

bumeye 14y ago
This is the way that github recommends (https://help.github.com/articles/creating-project-pages-manually 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.

tingletech 14y ago

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

roryokane 14y ago

EasyGit (http://people.gnome.org/~newren/eg/ 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 14y 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 14y 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.

lennartregebro 14y 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 14y 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.

deleted 14y ago

[deleted]