3 ms·
Did 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 w
by pascal_cuoq 13y ago
Did 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.