3 ms·
> 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 on
by 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 agoLook, 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.