Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Giovanni Biscuolo <g@xelera.eu>]

[-- Attachment #1: Type: text/plain, Size: 4823 bytes --]

Hello,

please consider I am (was?) a /great/ fan of rebase, but I have to admit
that "the golden rule" [1] of rebasing makes sense: «never rebase on a
public branch.»

Leo Famulari <leo@famulari.name> writes:

> On Sun, Jun 11, 2023 at 08:47:54PM -0400, Maxim Cournoyer wrote:
>> I'm not sure how that'd work, since Git only allows a single PGP
>> signature per commit, as far as I can tell.  When you rewrite the
>> history (by using rebase, say), the existing signatures of the rewritten
>> (rebased) commits are replaced with new ones generated from your key.
>
> Is it so bad to re-sign commits on feature branches that we should lose
> the easy-to-read history of rebased branches?

IMHO this is not a problem, at all.

> To me, it's much easier to understand and review a branch that has been
> updated by rebasing rather than merging. I think that counts for a lot.
> Do many people feel the same way?

Me! ...if you mean "it's much easier to understand the history" I agree,
but all in all this is "just" a "view" problem that should be solved (if
not already solved) by a proper git log "filter"

conversely, when rebasing the review process might be (sometimes very)
problematic, this is an excerpt from
«Why you should stop using Git rebase»
https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1

--8<---------------cut here---------------start------------->8---

Why do we use Git at all? Because it is our most important tool for
tracking down the source of bugs in our code. Git is our safety net. By
rebasing, we give this less priority, in favour of the desire to achieve
a linear history.

A while back, I had to bisect through several hundred commits to track
down a bug in our system. The faulty commit was located in the middle of
a long chain of commits that didn’t compile, due to a faulty rebase a
colleague had performed. This unneccessary and totally avoidable error
resulted in me spending nearly a day extra in tracking down the commit.

[...] Git merge. It’s a simple, one-step process, where all conflicts
are resolved in a single commit. The resulting merge commit clearly
marks the integration point between our branches, and our history
depicts what actually happened, and when it happened.

The importance of keeping your history true should not be
underestimated. By rebasing, you are lying to yourself and to your
team. You pretend that the commits were written today, when they were in
fact written yesterday, based on another commit. You’ve taken the
commits out of their original context, disguising what actually
happened. Can you be sure that the code builds? Can you be sure that the
commit messages still make sense? You may believe that you are cleaning
up and clarifying your history, but the result may very well be the
opposite.

--8<---------------cut here---------------end--------------->8---

Also, when I read the below mentioned article I have many doubts that
rebase should ever be used in Guix public feature branches:

«Rebase Considered Harmful»
https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

--8<---------------cut here---------------start------------->8---

2.1 A rebase is just a merge with historical references omitted

[...] So, another way of thinking about rebase is that it is a kind of merge
that intentionally forgets some details in order to not overwhelm the
weak history display mechanisms available in Git. Wouldn't it be better,
less error-prone, and easier on users to enhance the history display
mechanisms in Git so that rebasing for a clean, linear history became
unnecessary? [...]

2.2 Rebase does not actually provide better feature-branch diffs

[...] The argument from rebase advocates is that with merge it is
difficult to see only the changes associated with the feature branch
without the commingled mainline changes. In other words, diff(C2,C7)
shows changes from both the feature branch and from the mainline,
whereas in the rebase case diff(C6,C5') shows only the feature branch
changes.

But that argument is comparing apples to oranges, since the two diffs do
not have the same baseline. The correct way to see only the feature
branch changes in the merge case is not diff(C2,C7) but rather
diff(C6,C7). [...]

(n.d.r. see graphs on original page for clearness)

--8<---------------cut here---------------end--------------->8---
(IMHO the whole article deserves to be read)

[...]

WDYT?

Happy hacking! Gio'


[1] https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing


P.S.: and yes, maybe Fossil is better designed than Git, but I'm not
proposing switching to it, not at all :-)

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]