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