Hello. I wouldn't be surprised if this very subject has already been endlessly discussed over the years, but nevertheless allow me to make a feature request for git. (If this has already been discussed in the past, which I'm quite certain it has, I would like to hear the details so I can understand the design decisions that have been made in this regard.) Rebasing is a rather curious feature of git in that it's both an extremely common and normal operation done in many projects, and at the same time it's a very drastic measure that has the potential of badly messing up or even breaking git commit histories (as any operation that changes history is), or at a very minimum cause a lot of work. Rebasing is extremely common in many projects, so much so that there are many such projects where in fact only fast-forward merges are allowed to the master branch (which is often possible only by rebasing the branch to be merged onto the current master branch head). On the other hand, rebasing, as any other operation that changes commit history, has the potential of breaking things, or causing a ton of extra work, when more than one developer has the same branch checked out (and thus their local history diverges from the remote history). So, given how relatively common it is to use rebasing, and how carefully it should be used, it's a bit strange how poorly git seems to handle it. Not in terms of doing the rebasing itself, but in terms of subsequent operations done to the rebased branch. For starters, if your current branch has been pushed to the remote, and then you rebase it to something else, and then do a "git status", it will tell you that the local and remote histories have diverged... and then suggests doing a "git pull"! Which is most definitely not what you want to do! You just rebased the branch, you don't want to try to merge it with the old branch history! (Developers who have not encountered this before may become really confused if they try the "git pull" and start getting tons of really strange merge conflicts. The absolute worst thing they could then do is try to "resolve" those conflicts, which is most definitely not what you want to do! I don't know if there are situations where you actually *don't* get any merge conflicts and the two diverged histories just merge... creating a complete mess of a hybridized duplicated history.) I think that git should be aware of what has happened, in other words, that the current local branch has been rebased to something else, and is now a completely different history from the same branch in the remote, and express this clearly and suggest the correct thing (primarily to do a "git push -f"). More importantly, I think git should handle better the situation where you are trying to pull a rebased branch (which was rebased by someone else) onto your local original non-rebased one. Again, currently you'll just get a huge bunch of weird merge conflicts (if you are lucky), and the worst thing you could do is try to "resolve" them, as that's precisely what you shouldn't be doing. I understand that the branch history having changed on the remote can be a nightmare to deal with, when you have a local non-rebased copy of it, especially if you have made new local commits to it. AFAIK there are no easy clear-cut solutions to this, but one of them is to just write down the hashes of your commits, reset to the remote branch, and then cherry-pick your commits in chronological order (resolving any merge conflicts that may happen). The problem is that git isn't exactly helping here. I think that git should recognize the situation and give better suggestions on what to do. In other words, if you are doing a "git pull" and the remote branch has been rebased, git should stop and tell clearly that this has happened, and suggest what to do. If it detects that the local branch is identical to the old remote branch (that existed before the rebase), it could suggest a reset. If it detects that there are new local commits on top of the old history, it could make another suggestion on how to deal with it. It might also give the (rather unsafe) option of doing the pull anyway, for example with something like "git pull -f", with a huge warning. Perhaps git could even support the "reset-to-the-remote-history and then cherry-pick your new local commits" directly, to help the developer in this task (so that you don't need to write down any hashes and do all that manually). But even if this isn't really feasible, at least detecting the situation and the clearer messages would help enormously. (I understand that the current design of git might not directly allow this with just some code changes, and would perhaps require adding some kind of extra metadata. But would this be bad? It would certainly help developers handle rebases better.)
