Rebasing vs. merging

[Teemu Likonen]

* 2020-08-17 20:43:02+02, Lars Ingebrigtsen wrote:

> There's "philosophical" issues with rebasing (in that you're
> pretending that your own changes are newer than the remote ones), but
> that's not something we care about.

Another "philosophical" issue with rebasing is that the resulting code
is not necessarily tested anymore. I mean:

 1. Write new code based on upstream commit AAAA.
 2. Test the new code: OK, it's working.
 3. Want to push the code to the upstream.
 4. Upstream branch has advanced to commit BBBB.
 5. "git pull --rebase" so that the new code is now based on BBBB.
 6. "git push" pushes untested code to the upstream.

The new code is not tested because the code's base commit is not the
same. The committer may insist that everything was OK and really tested
but actually he didn't really test the resulting code. It's easy to fix
the procedure:

 6. Test the code again.
 7. "git push"

But it could be argued that it's nicer to show person's own and other
people's works in separate development branches and that is what merging
does. So it can be seen: "My branch really worked, just 'git checkout'
it and try, but it broke when I merged it with the upstream. Now let's
find out why these two branches together cause trouble." Maybe this kind
of recorded development history is useful in bug hunting too.

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

signature.asc
Description: PGP signature