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.
As someone who's only used git in fairly straightforward ways, that line is complete gibberish to me.
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.
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 wha…
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.
Wait until you see what happens when you type "rm -rf .git". Oh noes, the rm tool lets me DELETE HISTORY!
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.
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.
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.
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.
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.
>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.
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 wha…
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.
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 wha…
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 in…
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.
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.
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 wh…
You are of course correct.
However on Gits' homepage: "Git is a free and open source distributed version control system".
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.
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.
Sure, that's OK. But shouldn't that command be explicit?
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 tha…
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.