Die Git Die(github.com)
github.com
Die Git Die
https://github.com/regebro/die-git-die
99 comments
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.
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 unified timeline that will allow me (or now others) to more easily maintain and understand it going forward, and that was easy: git is an amazing tool for this very kind of manipulation that arguably is defeating its purpose, but in fact is enabling it to be useful at all (as the distributed engineer case involves a lot of personal rebasing and push forcing).
Again, though, if you want something simple: use Subversion. I'm going to continue to use git. This is despite having been an early adopter of Subversion, despite having contributed patches to Subversion, despite having contributed code to third-party tools built for Subversion, despite having spent time bonding with the developers of Subversion around late-night literal-campfires, and despite disagreeing with much of the anti-Subversion hype.
This tool doesn't suck: you just don't understand the advantages of using a manual transmission currently, nor maybe does a manual (and unguarded) transmission actually offer you any advantages for your unique position in life. I get that, that's fine... but it had a warning label... it had a massive danger notice, as they know sometimes people but the wrong thing, and you seem to have ignored it... your insistence that all cars should be unbreakable workhorses actually trumped your willingness to believe that the people who built the tool were telling you the truth, and you ignored the warning. That isn't as fine ;P.
(topic change)
By the way, you may continue to have the complaint that one engineer using git can damage history for others using "push -f". In fact, I used to have this same complaint, and went on similar rants to this article regarding it, but instead of complaining about me and how I might purposefully or accidentally lose my own work, it was about how I couldn't trust the server to not allow others to accidentally lose my work. You might not be, but just in case, there are two answers to that.
First, that is actually a misuse of a distributed revision control system: GitHub mistrains a bunch of people to share repositories, but git is designed on the premise that you only "push" to repositories you, the sole engineer, are the total owner of. You then send a "pull request" or a "formatted patch" to other people you are collaborating with, who then have you setup as a "remote" (likely with a "tracking branch"), and then they pull from you.
However, just in case you (or whomever is reading this) really don't care and just must use git this way (with a single centralized repository shared between multiple collaborators), as of 1.6 they added some configuration variables "recieve.denyNonFastForwards" and "recieve.denyDeletes" that cause the server to reject destructive activities. Alternatively, you can install custom hooks that provide this kind of behavior only for some branches, some users, or some other specific circumstances (maybe only on Tuesday ;P).
(One last thing: what you wanted to help you undo what you did was "git reflog", for future reference. Unless you manually override it, git actually stores recent--maybe 30 days worth of?--fifth-dimensional history, allowing you to see what you have been doing as you manipulate the fourth-dimensional timeline, and to allow you to somewhat-easily revert mistakes you may have made.)
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 unified timeline that will allow me (or now others) to more easily maintain and understand it going forward, and that was easy: git is an amazing tool for this very kind of manipulation that arguably is defeating its purpose, but in fact is enabling it to be useful at all (as the distributed engineer case involves a lot of personal rebasing and push forcing).
Again, though, if you want something simple: use Subversion. I'm going to continue to use git. This is despite having been an early adopter of Subversion, despite having contributed patches to Subversion, despite having contributed code to third-party tools built for Subversion, despite having spent time bonding with the developers of Subversion around late-night literal-campfires, and despite disagreeing with much of the anti-Subversion hype.
This tool doesn't suck: you just don't understand the advantages of using a manual transmission currently, nor maybe does a manual (and unguarded) transmission actually offer you any advantages for your unique position in life. I get that, that's fine... but it had a warning label... it had a massive danger notice, as they know sometimes people but the wrong thing, and you seem to have ignored it... your insistence that all cars should be unbreakable workhorses actually trumped your willingness to believe that the people who built the tool were telling you the truth, and you ignored the warning. That isn't as fine ;P.
(topic change)
By the way, you may continue to have the complaint that one engineer using git can damage history for others using "push -f". In fact, I used to have this same complaint, and went on similar rants to this article regarding it, but instead of complaining about me and how I might purposefully or accidentally lose my own work, it was about how I couldn't trust the server to not allow others to accidentally lose my work. You might not be, but just in case, there are two answers to that.
First, that is actually a misuse of a distributed revision control system: GitHub mistrains a bunch of people to share repositories, but git is designed on the premise that you only "push" to repositories you, the sole engineer, are the total owner of. You then send a "pull request" or a "formatted patch" to other people you are collaborating with, who then have you setup as a "remote" (likely with a "tracking branch"), and then they pull from you.
However, just in case you (or whomever is reading this) really don't care and just must use git this way (with a single centralized repository shared between multiple collaborators), as of 1.6 they added some configuration variables "recieve.denyNonFastForwards" and "recieve.denyDeletes" that cause the server to reject destructive activities. Alternatively, you can install custom hooks that provide this kind of behavior only for some branches, some users, or some other specific circumstances (maybe only on Tuesday ;P).
(One last thing: what you wanted to help you undo what you did was "git reflog", for future reference. Unless you manually override it, git actually stores recent--maybe 30 days worth of?--fifth-dimensional history, allowing you to see what you have been doing as you manipulate the fourth-dimensional timeline, and to allow you to somewhat-easily revert mistakes you may have made.)
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.
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?
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.
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.
You are of course correct.
However on Gits' homepage: "Git is a free and open source distributed version control system".
However on Gits' homepage: "Git is a free and open source distributed version control system".
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.
History not referenced will eventually be reaped by the garbage collector though.
Wait until you see what happens when you type "rm -rf .git". Oh noes, the rm tool lets me DELETE HISTORY!
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 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.
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.
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."
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."
you list, move, rename and delete branches with branch, but create branches using checkout? Seriously???
(I agree that git's interface is terrible, but I disagree that this is one of those cases. :) )
git checkout -b new-branch
git branch new-branch
git checkout new-branch
(I agree that git's interface is terrible, but I disagree that this is one of those cases. :) )
> 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
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
git branch -c new-branch
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.
I don't understand how creating a branch is a major operation.
Creating a branch is non-destructive and cheap, tidying up after accidental creation is also easy.
Creating a branch is non-destructive and cheap, tidying up after accidental creation is also easy.
Except, why isn't it "git branch --nocheckout" for the rare cases when you don't want to check out?
Why doesn't "mkdir" cd you into the new subdir unless you type "mkdir --no-cd my-dir"?
Here's why: In 95% of the cases you create a git branch, you check it out. In 95% of the cases you create a directory, you do not cd into it.
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.
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.
[deleted]
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. :(
Git pull does a git fetch of the branch specified and then does a git merge into the current branch.
[deleted]
"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!
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 understand Hacker News is a place for "serious" discussion, but a good Simpsons' reference always deserves props.
No one who writes a version control rant could be an evil man.
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.
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-...
[0] http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-...
But VS won't require using command line
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.
"The git, the?"
And feminine, at that?
And feminine, at that?
I totally agree that this is surprising behavior. But git did try to tell you:
! [rejected] master -> master (non-fast-forward)
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.
An evil prank would be to change someone's 'git push' alias to use -f by default.
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.
> 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.
> 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.
This is the reason pulling all matching branches (and pushing all matching branches) by default is generally a bad idea.
> However, git will not pull matching branches. That means that all your branches except your current branch will not get updated when you pull.
This is why git-up was created: https://github.com/aanand/git-up
It's silly that this is necessary, but "gem install git-up" and then run "git up" instead of "git pull" and you'll be much happier.
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.
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.
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.
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
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'.
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'.
I haven't seen the video but generally he's been very complimentary of BK:
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.
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.
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>I never knew of the local remote tracking branches in git until now. I just went and looked it up and found this post that explains it more http://longair.net/blog/2009/04/16/git-fetch-and-merge/
git branch -r
That's equivalent to just doing `git pull --rebase`, no?
`git pull --rebase` does not update my remote tracking branch. Though you may not care about this.
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).
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.
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.
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 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)/
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 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 :)
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):
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.
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 (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`.
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?
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
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 is the way that github recommends (https://help.github.com/articles/creating-project-pages-manu...).
A separate folder for the gh-pages branch makes sense because this branch has nothing in common with any of the other branches. It doesn't share any code or commits with your master branch.
The repository actually has two base commits and it's like two repositories contained in one. Thus needing two separate folders.
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.
> $ git push origin gh-pages
I think that if you had changed the above to
I think that if you had changed the above to
$ git push -u origin gh-pages
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.
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.
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.
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.
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.
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 http://www.git-legit.org ?
Looks like it was inspired by a hackernews comment https://news.ycombinator.com/item?id=2684483 and it replaces these commands
Looks like it was inspired by a hackernews comment https://news.ycombinator.com/item?id=2684483 and it replaces these commands
[deleted]
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 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.
You are confusing 'implementation details' with how does git abstract reality. You are not supposed to know how things are implemented, really.
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
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
GUI != UI
parent comment is arguing that the command-line interface is nontrivial, which is a fair criticism. Contrast with 'cp' or 'mv'
parent comment is arguing that the command-line interface is nontrivial, which is a fair criticism. Contrast with 'cp' or 'mv'
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.
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.
To use wget, I often need to read the manual or look up some notes to get the exact command I want.
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.
Git user interface is fine when you finally learn how to use git.
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.
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.
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.
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.
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.
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.
Github is the one who wants you to use git. This is why github built you a gui.
man gittutorial[deleted]
s/git/hg/ and get on with life.
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?