5 ms·

rebase uses the same merge logic as merge. What some people don't get is that if there were three commits pulled down form a remote, and you had three commits,

by rplst8 10y ago

rebase uses the same merge logic as merge. What some people don't get is that if there were three commits pulled down form a remote, and you had three commits, and you had conflicts (different ones) on each of those commits, rebase makes you resolve them one by one so it can literally "replay" those commits on top of the tip of the branch you are rebasing onto. That's why rebase is so cool. It lets you solve each conflict during the merge of each commit separately. Then you can do it interactively and squash it all into one commit. Learn the tools, don't complain.

aninhumer 10y ago
> It lets you solve each conflict during the merge of each commit separately. Which is what they're complaining about, compared to just merging and doing it once. Sometimes resolving smaller chunks at a time can be easier, but almost as often it involves a lot of extra effort creating intermediate states for little benefit, and often they don't even make sense. I much prefer to keep an accurate history, rather than invent one that I think looks neater (the same goes for squashing commits). And honestly I think a lot of what people object to can be mitigated by learning how to use git log properly.
- rplst8 10y ago
  Look, if I make 15 commits, to my local repo, some with major functionality additions, some with bug fixes, and some with typo fixes - I shouldn't have to share that whole history with the remote. Nor would anyone want me to. The re-writing history part only really applies to your local repo. If you re-write history on the remote, you are going to piss some people off.
  - aninhumer 10y ago
    >I shouldn't have to share that whole history with the remote. You don't have to share it, but why not? It might be useful in some cases, and people don't have to look at it the rest of the time. They can just look at merge commits, which are almost always coherent changes. Instead of relying on people to invent continuity, which might not even make sense.

by rplst8 10y ago

aninhumer 10y ago

> It lets you solve each conflict during the merge of each commit separately. Which is what they're complaining about, compared to just merging and doing it once. Sometimes resolving smaller chunks at a time can be easier, but almost as often it involves a lot of extra effort creating intermediate states for little benefit, and often they don't even make sense. I much prefer to keep an accurate history, rather than invent one that I think looks neater (the same goes for squashing commits). And honestly I think a lot of what people object to can be mitigated by learning how to use git log properly.

rplst8 10y ago
Look, if I make 15 commits, to my local repo, some with major functionality additions, some with bug fixes, and some with typo fixes - I shouldn't have to share that whole history with the remote. Nor would anyone want me to. The re-writing history part only really applies to your local repo. If you re-write history on the remote, you are going to piss some people off.
- aninhumer 10y ago
  >I shouldn't have to share that whole history with the remote. You don't have to share it, but why not? It might be useful in some cases, and people don't have to look at it the rest of the time. They can just look at merge commits, which are almost always coherent changes. Instead of relying on people to invent continuity, which might not even make sense.