Re: Rebasing vs. merging

[Kévin Le Gouguec]

Teemu Likonen <tlikonen@iki.fi> writes:

> 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.

How is the --rebase flag responsible for the ultimate issue (untested
code pushed upstream)?  Step 6 could happen just as well with a merge
unless I'm missing something?

>       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.

Focusing on merge commits may be a good heuristic to find *when*
(i.e. at which recorded point in the VC history) things broke, but it's
not a big help to find *why* IMO.  No issue will show up on either
branch until the merge, so you're just left with an unintelligibly big
diff to make sense of.

When it comes to bug hunting, I find it more straightforward to bisect
on a linear history.  Eventually I'll find which rebased commit is
responsible for the breakage, and it will be easier to find the issue in
this individual commit's diff.


I don't have a strong opinion on rebasing vs. merging, although FWIW I
do find merge commits noisy, and as explained above they make it less
straightforward (for me) to bisect.