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)/
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.
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.
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.
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.
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."
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.
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.
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.
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.
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.
To be honest, none of the issues I've seen are in any way dependent on workflow. That pull and push by default work on different branches is not a matter of workflow, it's a confusing inconsistency.
That it deletes history without somebody issuing an explicit specific command to delete a specific revision is not a matter of workflow, it's bad design.
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!
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.
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.
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.
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.
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. :(
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."
"Branch" is a major, repo-modifying operation; "checkout" is a trivial context switch operation. The user interface disaster here was that the major operation is treated as subservient to the trivial operation. It should be the other way around.
Therefore, the shortcut for creating a branch and switching to it should be
git branch -c new-branch
whereby the -c switch checks you into that branch immediately.
branches aren't supposed to be "major". That's the major difference between a system like git and svn. branches are cheap. They are supposed to be used often and even be disposable.
Indeed. "git branch" is a lot like "mkdir". If you accidentally make a branch, deleting it with "git branch -d my-branch" is about as easy as typing "rmdir my-dir".
For me, it's about 50% for each. I often create a branch just to snapshot the current state of the branch before squashing or rebasing. When I do this, I do not checkout the new branch, and in fact, most likely I will never check it out.
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.
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?
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.
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.
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).
And that simile also has nothing to do with what happened.
First of all, this is not a matter of me doing something wrong because I didn't learn enough of gits internals or didn't understand the cryptic the error message. The problem is that the error message appeared in the first place. In a sane revision control system, that would never have happened. Or at least, if a push fails because of a conflict, a git pull should have solved that.
This is not a matter of damaging the engine by revving it, or damaging anything else by misusing it. Because the history is not the engine, nor is it a child in a child seat. If you are going to use car similes, and you started it, then git is the car, and the history in your repo is your travels. The error message hence says:
"I'm sorry, you can't press the has pedal hard right now, because your engine is really a dwarf on a bicycle, and he is busy going to the loo. If you press the gas pedal hard now, the car will move, but you will suddenly appear where you were yesterday!"
Is that a sensible error message to you? Now, this is a road where you can take backup of where you are. So I did that, and tried, and to my astonishment the error message was right. The engine in my car was a dwarf on a bike, and I did find myself back where I was yesterday.
And the only way to avoid these things happening is : 1: backups or 2: Learning how the car is built from scratch, so I never press the wrong button or pedal again.
And you know what? That makes the car a crappy car. Requiring intimate knowledge about how to build and repair a car is something you needed in the infancy of automotive power. Not now. And it was something you needed when using RCS and CVS etc. Subversion solved that. Suddenly you could use a revision control system without knowing everything about how it is implemented in detail. But with git, we are suddenly thrown back to the RCS days.
That's the point, and that's why git sucks, and no misguided and incorrect car simile from your point can change that.
The goal of an analogy is to make you understand something that you did not understand previously by describing it in a different set of terminology. In this case, my analogy is only incorrect to you, as far as I can tell here, because you disagree with it so strongly you don't want to consider how it works.
I am thereby sorry that my analogy isn't quite working for you (indicating I could have tried harder), but if you could see the number of up votes it got given not-high this story got as a whole, you might consider spending some more time studying it to try to learn from it. I am going to try, though, as this may be valuable to others. Your complaint is that git failed to achieve its stated purpose: to never lose history, so lets examine what that means for the analogy.
In the case of the engine being destroyed, the car also failed to achieve its stated goal: to continue to be a vehicle for transport to new locations. The path the car travelled is thereby not a useful analogy, because it isn't something the car claims to do: it is a side effect of the car existing, and if you lost the path the car had previously travelled somehow you'd blame the space-time continuum, not the car.
The reason why git failed to do this, is because it trusts the user to know better than it in many of the same ways that a performance vehicle does. This is because both git and the car have similar secondary goals: they are willing to violate their primary mission statement to give the user easier access to direct control. Sometimes, direct control is dangerous.
To draw this again laboriously: the people who built the car understand that if it stops being a vehicle capable of moving you from one location to another, that sucks, and they technically could add features that make it very very difficult for you to break that; but, in the case of the performance-oriented vehicle, they chose not to do so, as maybe you actually are "making the call" to destroy the engine to, say, stop faster (I know someone who has done this, incidentally, someone who has a hobby maintaining and racing cars).
To compare, the people who developed git understand that if it stops storing your history in a way where you can always access it, that sucks, and while they technically could have made it more difficult for you to do that (either removing such features entirely or hiding them behind totally unrelated commands, like svnadmin), as they are making a lower-level engineer-focussed tool, they allow you to screw up and expect you to know what you are doing.
The analogy continues to be useful, as no one forced you to use the more advanced, lower-level, "raw", performance-oriented tool: you are welcome to use something that makes it very difficult to screw up. If you don't like Subversion (which has a lot of advantages for this use case) you can use Mercurial, which as far as I remember makes this kind of history manipulation quite difficult.
The situation here is simply that you chose a tool that you should not have and which did not match your expectations, and it isn't because the tool "sucks"... it is just because you aren't in the target market for the tool. The reason why people like myself are using git right now is not because it is somehow fundamentally better than Subversion at simple tasks (most of the complaints about Subversion are about old versions, honestly, and darcs seems to have a much better way of thinking about the concept of patches), it is because sometimes we run into really hard tasks that it makes possible (such as managing a distributed collective of thousands of engineers, some of which are totally disconnected from others).
It is then git's insistence to make some of these hard tasks possible that directly leads to the kind of "I lost my history?" problems you ran into. As as example, I just spent the last two days "manipulating the past" in order to take some code that I had previously been maintaining as part of two separate projects (with three separate copies...), and get it all pulled into a single place with a un...
Mistakes like this happen often, being able to purposefully delete history (at least as far as the remote is concerned) is a very important feature of a VCS.
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.
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.
Just to be clear here, since I think the combination of quickly and garbage collection is likely to create a wrong impression: quickly means days/weeks, not seconds.
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.
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.
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>
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).
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.
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.
>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.
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'.
And two basic verbs 'pull' and 'push' are straight from BK.
My impression's been that the crazy command set is in part due to the early design idea that the basic commands represent primitives that operate on the fundamental git model on top of which something, potentially separate and more human-friendly will be built. Except it didn't quite work out that way.
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 :)
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.
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.
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?
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.
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`.
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.
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.
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.
99 comments
[ 3.1 ms ] story [ 189 ms ] threadI'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)/
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
parent comment is arguing that the command-line interface is nontrivial, which is a fair criticism. Contrast with 'cp' or 'mv'
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.
Git user interface is fine when you finally learn how to use git.
I don't think your reasoning holds. That's why we have abstractions, to make hard things easy.
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.
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.
I think that if you had changed the above to
then everything else would have gone smoothly.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.
My point is not that git is impossible to use. It's that the way git behaves by default is insane.
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.
That it deletes history without somebody issuing an explicit specific command to delete a specific revision is not a matter of workflow, it's bad design.
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!
[0] http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-...
And feminine, at that?
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.
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."
(I agree that git's interface is terrible, but I disagree that this is one of those cases. :) )
I do think this is precisely one of those cases.
"Branch" is a major, repo-modifying operation; "checkout" is a trivial context switch operation. The user interface disaster here was that the major operation is treated as subservient to the trivial operation. It should be the other way around.
Therefore, the shortcut for creating a branch and switching to it should be
whereby the -c switch checks you into that branch immediately.Creating a branch is non-destructive and cheap, tidying up after accidental creation is also easy.
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.
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?
First of all, this is not a matter of me doing something wrong because I didn't learn enough of gits internals or didn't understand the cryptic the error message. The problem is that the error message appeared in the first place. In a sane revision control system, that would never have happened. Or at least, if a push fails because of a conflict, a git pull should have solved that.
This is not a matter of damaging the engine by revving it, or damaging anything else by misusing it. Because the history is not the engine, nor is it a child in a child seat. If you are going to use car similes, and you started it, then git is the car, and the history in your repo is your travels. The error message hence says:
"I'm sorry, you can't press the has pedal hard right now, because your engine is really a dwarf on a bicycle, and he is busy going to the loo. If you press the gas pedal hard now, the car will move, but you will suddenly appear where you were yesterday!"
Is that a sensible error message to you? Now, this is a road where you can take backup of where you are. So I did that, and tried, and to my astonishment the error message was right. The engine in my car was a dwarf on a bike, and I did find myself back where I was yesterday.
And the only way to avoid these things happening is : 1: backups or 2: Learning how the car is built from scratch, so I never press the wrong button or pedal again.
And you know what? That makes the car a crappy car. Requiring intimate knowledge about how to build and repair a car is something you needed in the infancy of automotive power. Not now. And it was something you needed when using RCS and CVS etc. Subversion solved that. Suddenly you could use a revision control system without knowing everything about how it is implemented in detail. But with git, we are suddenly thrown back to the RCS days.
That's the point, and that's why git sucks, and no misguided and incorrect car simile from your point can change that.
I am thereby sorry that my analogy isn't quite working for you (indicating I could have tried harder), but if you could see the number of up votes it got given not-high this story got as a whole, you might consider spending some more time studying it to try to learn from it. I am going to try, though, as this may be valuable to others. Your complaint is that git failed to achieve its stated purpose: to never lose history, so lets examine what that means for the analogy.
In the case of the engine being destroyed, the car also failed to achieve its stated goal: to continue to be a vehicle for transport to new locations. The path the car travelled is thereby not a useful analogy, because it isn't something the car claims to do: it is a side effect of the car existing, and if you lost the path the car had previously travelled somehow you'd blame the space-time continuum, not the car.
The reason why git failed to do this, is because it trusts the user to know better than it in many of the same ways that a performance vehicle does. This is because both git and the car have similar secondary goals: they are willing to violate their primary mission statement to give the user easier access to direct control. Sometimes, direct control is dangerous.
To draw this again laboriously: the people who built the car understand that if it stops being a vehicle capable of moving you from one location to another, that sucks, and they technically could add features that make it very very difficult for you to break that; but, in the case of the performance-oriented vehicle, they chose not to do so, as maybe you actually are "making the call" to destroy the engine to, say, stop faster (I know someone who has done this, incidentally, someone who has a hobby maintaining and racing cars).
To compare, the people who developed git understand that if it stops storing your history in a way where you can always access it, that sucks, and while they technically could have made it more difficult for you to do that (either removing such features entirely or hiding them behind totally unrelated commands, like svnadmin), as they are making a lower-level engineer-focussed tool, they allow you to screw up and expect you to know what you are doing.
The analogy continues to be useful, as no one forced you to use the more advanced, lower-level, "raw", performance-oriented tool: you are welcome to use something that makes it very difficult to screw up. If you don't like Subversion (which has a lot of advantages for this use case) you can use Mercurial, which as far as I remember makes this kind of history manipulation quite difficult.
The situation here is simply that you chose a tool that you should not have and which did not match your expectations, and it isn't because the tool "sucks"... it is just because you aren't in the target market for the tool. The reason why people like myself are using git right now is not because it is somehow fundamentally better than Subversion at simple tasks (most of the complaints about Subversion are about old versions, honestly, and darcs seems to have a much better way of thinking about the concept of patches), it is because sometimes we run into really hard tasks that it makes possible (such as managing a distributed collective of thousands of engineers, some of which are totally disconnected from others).
It is then git's insistence to make some of these hard tasks possible that directly leads to the kind of "I lost my history?" problems you ran into. As as example, I just spent the last two days "manipulating the past" in order to take some code that I had previously been maintaining as part of two separate projects (with three separate copies...), and get it all pulled into a single place with a un...
That's a sharp edge that should be exposed, and its not the only one in git.
History not referenced will eventually be reaped by the garbage collector though.
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.
However on Gits' homepage: "Git is a free and open source distributed version control system".
But don't get me wrong. On the whole, git is fantastic and a real improvement on its predecessors.
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.
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'.
http://marc.info/?l=git&m=114685143200012 http://marc.info/?l=git&m=116129092117475
And two basic verbs 'pull' and 'push' are straight from BK.
My impression's been that the crazy command set is in part due to the early design idea that the basic commands represent primitives that operate on the fundamental git model on top of which something, potentially separate and more human-friendly will be built. Except it didn't quite work out that way.
> 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.
Github is the one who wants you to use git. This is why github built you a gui.
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.
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.
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.
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
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?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.
Looks like it was inspired by a hackernews comment https://news.ycombinator.com/item?id=2684483 and it replaces these commands
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`.
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):