I feel tempted to just answer the question using the Betteridge Law of Headlines: Why is git pull considered harmful? It isn't.<p>- nonlinearities aren't intrinsically bad. If they represent the actual history they are ok.<p>- accidental reintroduction of commits <i>rebased</i> upstream are the result of wrongly rewriting history upstream. You can't rewrite history when history is replicated along several repos.<p>- modifying the working directory is an expected result; of debatable usefulness, namely in the face of the behaviour of hg/monotone/darcs/other_dvcs_predating_git, but again not intrinsically bad.<p>- pausing to review others' work is needed for a merge, again an expected behaviour on git pull<p>- making it hard to rebase against a remote branch is good. Don't rewrite history unless you absolutely need to. I can't for the life of me understand this pursuit of a (fake) linear history<p>- Not cleaning up branches is good. Each repo knows what it wants to hold. Git has no notion of master-slave relationships.
If git pull is causing problems for you, you are not using git correctly. You shouldn't be doing work on upstream branches -- that's one of the wonderful things about git, branching is cheap.<p>When working with more than 0 other people you should reserve the upstream branches for merging <i>your</i> work and pushing. Do your actual work in a branch and you can easily commit/stash our working tree, switch to the other branch and examine their changes.
The although the answer is quite thorough in almost every example you had to be doing something else incorrectly for git pull to be an issue.<p>I have often railed with other developers working on mid/large sized projects about having this pristine git history where commits are all tailed back to back. My main issue with this is the fact that you never get a commit for when two branches come together so you never really know when an issue was introduced.<p>i.e.<p>Branch A works.
Branch B work.<p>Branch A-B doesn't work. No merge commit to show introduction of bug.<p>People in general practice should not be force pushing.<p>Most of the arguments seem to be against not know what you are going to get which can be preempted with a fetch portion of git pull, but if you don't trust people you are working with, work with new people.<p>git pull doesn't delete old branch just as git add doesn't to delete old branches, I am not even sure making an argument like that means, its not what git pull is for.
This sort of "git pull" slam is really just an aftershock of shooting yourself in the foot.<p>The UX of git is so different from other tools, but seems so similar. It's a real problem for newbies. It's easy to think you know what's going on, because is vaguely similar to other operations. And, for the impatient, the documentation is really, really obnoxious. And most developers I've met are fairly impatient.<p>End result: most developers I've met has shot themselves in the foot when they started to use git.<p>When I bring people onto git now, I start them with a nice visual tool in an existing repo; my current favorite is SourceTree. But that's not a requirement. The simple fact that they can a nice history log with see tags of "origin/master" and "master" usually triggers that "WTF" experience and they start asking the right questions. If I start them with a new repo, and then have them add, and stage, it's all a bunch of things they could figure out, and they get impatient, and then bad things happen when it comes time to play with others.
Why was this link put into hacker news ? It's old, it is also based on inaccurate understanding of git. Experienced git users don't need this(1). Is Hacker news designed to publish hints for beginners ?<p>Hacker news aimed at links that are deeply interesting.<p>> "A crap link is one that's only superficially interesting. Stories on HN don't have to be about hacking, because good hackers aren't only interested in hacking, but they do have to be deeply interesting."<p>In my opinion, this link is superficial, and does not go in the real topic : the workflow.<p>(1) In my opinion, an experienced git user should know what he need to fetch, and when he should have a merge instead of rebasing some commits, and should also know the commands to do so. It's more a matter of workflow than a matter of git command.
I have never had an issue with git pull. With proper communication and push/pull etiquette, there will rarely be conflicts and when there are, just rebase. I don't think it is ever ok to force a push. If you are having trouble reviewing others commits then try using gitx to view the changes in an easy to read way. I like that it doesn't remove deleted branches because sometimes I still want it when the rest of the team doesn't. I'm not convinced..
So I take it that the poster is also the one who gets worked up when people use git pull? This person is criminally insane and I feel for his colleagues.
It's not harmful. It's just the surprising asymmetry between "git pull" and "git push": for some reason (which is obvious), "git push" does _not_ merge, whereas "git pull" does.<p>Again, compare with how perfectly symmetrical pull/push operations are in Mercurial.
Although SO does give one the option to answer an own question it is clear here that this guy posted his question in order to answer it, perhaps to farm points, perhaps because he thought his answer is genuinely useful. The answer is time stamped the same as the question.<p>Not sure why we should care one way or the other but to me it does seem a bit against the spirit of how SO should be used.
Seems obvious to me that git is just the tool we use to implement a specific workflow. If the developers don't understand or disagree about the workflow it will be a bumpy road. git pull is certainly part of our workflow but doesn't generate much pain at all.
The accepted answer on SO is to create an alias of a command sequence, including a git config for the command session.<p>It is really a git best practice to create custom commands for common operations?
I have a cronjob that does a "git fetch" every 5 minutes. That means I never pull. I merge-fastforward, and I rebase. Very satisfied with that workflow.
That post really irks me. Granted, S.O. encourages you to answer your own question, but this guy would have been much better served by a blog post. A Q&A is not the appropriate format for him to ask a question when he has no need for an answer. Seriously, blog it, dude.
Apparently a solution has been released for git 2.0.<p>> "git pull" can be told to only accept fast-forward by setting the
> new "pull.ff" configuration.