23 ms·
Why is git pull considered harmful? (2013)
- a3voices 13y agoIt's amusing how the same person posted and answered the question. It's almost like he's using Stack Overflow as a blog.
- mbrameld 13y agoIt may be amusing, but it's a feature of SO. When you ask a question it gives you the option of answering it yourself. This is so you can share the solution to a problem you have solved in case anyone else has the same problem in the future.
- userbinator 13y agoThus avoiding https://xkcd.com/979/ https://xkcd.com/979/ and the equally annoying "Nevermind, I fixed it."
- tommmmmm 13y agoIt's common and encouraged on SO to answer your own question. The comments on the question address the reasons why.
- dgellow 13y agoIt's a StackOverflow feature. The question has been asked before on Meta : http://meta.stackoverflow.com/a/17467 http://meta.stackoverflow.com/a/17467 Question: "Can I answer my own questions, even if I knew the answer before asking?" Answer: "Yes! There are already numerous posts that answer their own questions. There's nothing wrong with it. It's even encouraged."
- why-el 13y agoI think the amusing part is how long it took the asker to answer their own questions, suggesting that he asked only to answer right after. Nothing wrong with that, in fact I think it's great.
- masklinn 13y agoOddly enough, that's something which is not only allowed but encouraged: http://blog.stackoverflow.com/2011/07/its-ok-to-ask-and-answer-your-own-questions/ http://blog.stackoverflow.com/2011/07/its-ok-to-ask-and-answ... When you "ask a question" there's a checkbox at the end to "answer your own question". I guess it's the stuff one could do after spending hours tracking an issue and realising others could benefit from a google-juiced answer.
- cschmidt 13y agoI often answer my question if no one else does. But my process is: 1. post question on SO 2. realize I'm stuck, so spend the day figuring out the answer. 3. since no one else has answered, write up my solution I'm always hoping it goes: 1. post question on SO 2. get an immediate reply with the solution but that never seems to happen for me. I guess I ask the kind of questions that don't have quick answers.
- Cthulhu_ 13y agoYou mean the kind of question that is beyond 'how to read file in <language>? TBH I wish SO consisted only of that kinda questions (the difficult ones, that is)
- andyhmltn 13y agoI've done this a few times actually. If it's a problem that I can't find the solution to using Google and I suddenly solve it, I'll answer it on SO so other people can benefit in future :)
- dimillian 13y agoPlease remember that the goal of SO is to share knowledge. The point/karma system is the cherry on top.
- dgritsko 13y agoIt's very much inline with the "original vision" for StackOverflow, as represented here: http://blog.codinghorror.com/content/images/uploads/2008/09/6a0120a85dcdae970b012877705441970c-pi.png http://blog.codinghorror.com/content/images/uploads/2008/09/... Also, see http://blog.codinghorror.com/stack-overflow-none-of-us-is-as-dumb-as-all-of-us/ http://blog.codinghorror.com/stack-overflow-none-of-us-is-as...
- nikon 13y agogit pull --rebase
- pascal_cuoq 13y agoDid you read the linked webpage? The problems of “pull --rebase” are addressed, and the author offers an alternative solution. I am not expert enough to judge whether there still are problems with his solution, but I can assure you that your comment is not adding anything to the debate.
- ShaunK 13y agoI read the linked webpage, and I have had none of the issues he seems to think occur with git pull --rebase. I believe he uses git differently than I, and many other people, do. Whenever I'm about to begin work I create a new branch. I git pull --rebase that branch with the upstream branch I am going to merge with frequently while I work. I've never had any unexpected behaviour.
- krisdol 13y agoThe linked webpage does not mention git pull --rebase. The author talks about problems with setting the configuration options of git pull to any one default, but doesn't address the fact that we can perform a fetch, merge, rebase in one command when necessary with "git pull --rebase". The default configuration is preserved in this case. That said, I have none of the issues the SO guy has. It's insane that he has so many problems with people "cleaning up" a remote's history by making it more linear than it actually is. You should never force push and you should never rebase pushed commits. There are very few exceptions to this rule.
- bcl 13y agoIf 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. When working with more than 0 other people you should reserve the upstream branches for merging your 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.
- hrjet 13y agoThis is a fine suggestion for large, systematically developed projects. But for hobby projects supported by an occasional community contribution, branching everytime can be cumbersome.
- yock 13y agoIt really isn't. It takes almost no effort to `git checkout -b feature-branch` before an add and commit.
- gbog 13y agoExcept that you need to know what you will do in advance, in order to give a meaningful name to the branch, and you need to delete odds branches in order to find your way when switching, et cetera. The first point is stronger than it seems, at least for me. It is a bit like requiring a definitive title to a novel I'm starting to write before the first line is there.
- jstclair 13y agoTo rename: git branch -m old-name new-name Candidate branches for deletion: git branch --merged
- Crito 13y agoBranches are literally just text files that contain a sha in refs/heads. The name of the file is the name of your branch. They are an incredibly lightweight concept that should never be considered the source of any sort of technical debt.
- websitescenes 13y agoI 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..
- SeanDav 13y agoAlthough 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. 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.
- massysett 13y ago"If you have a question that you already know the answer to, and you would like to document that knowledge in public so that others (including yourself) can find it later, it's perfectly okay to ask and answer your own question on a Stack Exchange site." http://stackoverflow.com/help/self-answer http://stackoverflow.com/help/self-answer
- DrJokepu 13y agoAFAIK you don't get reputation for answers to your own questions.
- maaaats 13y agoYou do get rep. I occasionally get reputation for my own answer to my own question ( http://stackoverflow.com/q/12077126/923847 http://stackoverflow.com/q/12077126/923847 ). If you got some nice info, why should one not be able to share it? If you get rep, it means that it was useful for someone.
- haversine 13y agoI think you only don't get the 15 rep for selecting your own answer as the correct one. Upvotes still give you rep.
- LanceH 13y agoIt is only point farming if it turns out to be useful, which is the whole point of SO.
- blt 13y agohttp://blog.stackoverflow.com/2011/07/its-ok-to-ask-and-answer-your-own-questions/ http://blog.stackoverflow.com/2011/07/its-ok-to-ask-and-answ... > To be crystal clear, it is not merely OK to ask and answer your own question, it is explicitly encouraged.
- deleted 13y ago[deleted]
- badman_ting 13y agoOh cripes. I just want to do my work and commit my code.
- flogic 13y agoYeah... Badgering your co-workers over using the standard tools in the standard manor is just being a jerk.
- Cthulhu_ 13y agoAnd that's fine, as long as you're the only one working on your codebase.
- mcv 13y agoThen just stick to `git pull`, `git commit` and `git push`. They do everything you need. All that messing about with your history that this guy is talking about is totally unnecessary.
- jebblue 13y agoAgreed, that's what I stick to and git has been working great, very fast. I've noticed that if a push fails, all I have to do on the master is: git checkout -b foo // do the push from the client repo git branch -d foo
- jordigh 13y agoMeanwhile, "hg pull" is just fine (it really works more like git fetch). This really is just another case of bad UI design in git.
- Crito 13y agoWhy is "hg pull" being equivalent to "git fetch" bad UI on the part of git? Just because it is different from Hg? I use git-fetch, and have never had a problem with it being called "fetch".
- anton_gogolev 13y agoIt'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. Again, compare with how perfectly symmetrical pull/push operations are in Mercurial.
- etherealG 13y agomind explaining what hg push/pull do to a git only user? perhaps it's that i'm just only used to git's definitions of the words, but they seem symmetrical to me in the sense that they both try to synchronise history, either upwards or downwards. i can't really imagine what a pull would do differently than a merge or rebase that would satisfy the idea of synchronisation but be more symmetrical as you describe. i'd really appreciate an elaboration.
- anton_gogolev 13y ago"hg push" does nothing fancy: it just prepares a bundle [1] and sends it over to the server. The server can either reject (when committing a bundle will result in creation of a new head) or accept (either by virtue of --force flag or just because it does not create any new heads) the bundle and transactionally commit it to the repository. If the repository being pushed to is not "bare" (in Git parlance), it's working copy will not be affected by a push operation. Note that there's no merging going on here. All the merging/rebasing/rewriting happens before "hg push". Now, "hg pull" does perfectly symmetrical thing: it downloads a bundle from the server and commits it to the local repository. Working copy is not affected at all. Again, merging/rebasing happens elsewhere, outside of "hg pull" workflow. [1]: http://mercurial.selenic.com/wiki/BundleFormat http://mercurial.selenic.com/wiki/BundleFormat
- Jacen 13y agoWhy 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 ? Hacker news aimed at links that are deeply interesting. > "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." In my opinion, this link is superficial, and does not go in the real topic : the workflow. (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.
- mcfunley 13y agoSo 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.
- googletron 13y agoThe 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. 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. i.e. Branch A works. Branch B work. Branch A-B doesn't work. No merge commit to show introduction of bug. People in general practice should not be force pushing. 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. 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.
- merloen 13y agoI 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.
- sergiosgc 13y agoI feel tempted to just answer the question using the Betteridge Law of Headlines: Why is git pull considered harmful? It isn't. - nonlinearities aren't intrinsically bad. If they represent the actual history they are ok. - accidental reintroduction of commits rebased upstream are the result of wrongly rewriting history upstream. You can't rewrite history when history is replicated along several repos. - 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. - pausing to review others' work is needed for a merge, again an expected behaviour on git pull - 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 - Not cleaning up branches is good. Each repo knows what it wants to hold. Git has no notion of master-slave relationships.
- tvon 13y agoPerhaps you should post a response to keep things from being so one-sided.
- Linell 13y agoSomeone definitely should. For those of us who aren't super experienced, it would be good to hear both sides of the story in the same place.
- mcv 13y agoYeah, I'd vote that answer up. If sergiosgc won't post it on stackoverflow, maybe I will. (My notice my comment there has already been upvoted quite a bit.)
- haptiK 13y agoI agree. This retort should be posted for a balanced view of the topic.
- sergiosgc 13y agoThanks for the suggestion. I just posted the answer there [1]. [1] http://stackoverflow.com/a/22355851/383868 http://stackoverflow.com/a/22355851/383868
- mokkol 13y agoI use git-up for this issue. https://github.com/aanand/git-up https://github.com/aanand/git-up
- bsg75 13y agoThe accepted answer on SO is to create an alias of a command sequence, including a git config for the command session. It is really a git best practice to create custom commands for common operations?
- mcv 13y ago> It is really a git best practice to create custom commands for common operations? No, of course not. But this isn't a guy asking an honest question, this is a guy venting his opinion and showing how to use git with his unusual way of working, which is possible. But his way of working is not a git best practice. It's just one of the many, many options you have with git.
- frabcus 13y agoExcellent question! I've several times been told to make git aliases. I'm very reluctant to, because I know in practice different people and different machines will have different aliases, making a friction on collaboration and knowledge sharing.
- richardjordan 13y agoAh. So THIS is how you juice your stack overflow ranking. Good to know.
- jheriko 13y agoisn't this just another very special case of 'modifying history is harmful'?
- zwieback 13y agoSeems 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.
- Guvante 13y agoApparently a solution has been released for git 2.0. > "git pull" can be told to only accept fast-forward by setting the > new "pull.ff" configuration.
- tristan_juricek 13y agoThis sort of "git pull" slam is really just an aftershock of shooting yourself in the foot. 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. End result: most developers I've met has shot themselves in the foot when they started to use git. 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.
- joshlegs 13y agoThat 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.
- evanm 13y agow/e. i <3 git pull
- njharman 13y agoWhy is git so god damn hard / complicated? I mean other than haven been created by and for Kernel Developers.
- deleted 13y ago[deleted]
- unethical_ban 13y agoAnother example of how complex git can be. How I wish git's interactions were more like bzr!