3 ms·

Does this explanation help? http://bryan-murdock.blogspot.com/2022/12/git-rebase-explained.html http://bryan-murdock.blogspot.com/2022/12/git-rebase-explain...

by krupan 3y ago

Does this explanation help? http://bryan-murdock.blogspot.com/2022/12/git-rebase-explained.html http://bryan-murdock.blogspot.com/2022/12/git-rebase-explain... Rebase is really a merge (actually one merge per commit you are rebasing). At least it should be. With mercurial it really seems to be. With git I'm not so sure because it feels like it's always worse at resolving conflicts than mercurial. I haven't tested it thoroughly or looked at the implementations

nerdponx 3y ago
Interesting that this article omits any mention of "cherry-pick".
kelnos 3y ago
I don't think that's a very good explanation. It only considers one possible use of rebase, to resync a feature/topic branch with a main branch that has diverged since the branch was created. Another common use case for rebase is to clean up an already-linear history. And even then, when using rebase to "resync" different branches, I don't think it's accurate to characterize it as a merge at all. It's a hard reset plus a series of cherry-picks. (As an aside, this is why rebase can be much more annoying than a merge! Merging a branch onto another is usually quick and easy. Git's merge algorithms usually do a decent job of figuring out how to do a merge without conflicts. And if there are conflicts, you only have to resolve them once. If instead you rebase, you may have to resolve the same (or similar) conflicts over and over and over, once for each cherry-pick. And there might be conflicts that wouldn't have even occurred with a simple merge. Git's rerere mechanism does automate some of it, sometimes, though.)
- krupan 3y ago
  A couple things. That blog post shows the case of rebasing a single commit and so yes, it doesn't talk about interactive rebase that lets you reorder and edit commits, and it doesn't talk about rebasing multiple commits. In the case of multiple commits, it has to perform a merge operation for each of those commits, that's why you end up seeing the same merge conflicts over and over. For interactive rebase, there are so many scenarios there that it would probably take a few posts to explore them all.

by krupan 3y ago

nerdponx 3y ago

Interesting that this article omits any mention of "cherry-pick".

kelnos 3y ago

I don't think that's a very good explanation. It only considers one possible use of rebase, to resync a feature/topic branch with a main branch that has diverged since the branch was created. Another common use case for rebase is to clean up an already-linear history. And even then, when using rebase to "resync" different branches, I don't think it's accurate to characterize it as a merge at all. It's a hard reset plus a series of cherry-picks. (As an aside, this is why rebase can be much more annoying than a merge! Merging a branch onto another is usually quick and easy. Git's merge algorithms usually do a decent job of figuring out how to do a merge without conflicts. And if there are conflicts, you only have to resolve them once. If instead you rebase, you may have to resolve the same (or similar) conflicts over and over and over, once for each cherry-pick. And there might be conflicts that wouldn't have even occurred with a simple merge. Git's rerere mechanism does automate some of it, sometimes, though.)

krupan 3y ago
A couple things. That blog post shows the case of rebasing a single commit and so yes, it doesn't talk about interactive rebase that lets you reorder and edit commits, and it doesn't talk about rebasing multiple commits. In the case of multiple commits, it has to perform a merge operation for each of those commits, that's why you end up seeing the same merge conflicts over and over. For interactive rebase, there are so many scenarios there that it would probably take a few posts to explore them all.