<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
For seL4 we also have a rebase workflow in git. It’s possible to do in hg, but not as nicely and needs people who know how to deal with it.
<div><br>
</div>
<div>Given the problems people get into with just plain hg, I don’t think it would be a good idea for Isabelle or the AFP. It also doesn’t fit with our commit culture on Isabelle ("tuned;"). I would advise against.</div>
<div><br>
</div>
<div>I do feel the need to point out that we have long-running branches in our rebase workflow (months, not years, but not daily) — that works perfectly fine if you rebase your branch frequently enough over the trunk, you don’t need to integrate back frequently.
 But the main benefit of rebase branches is a linear, rational commit history, i.e. a history that is not true but that is the history you would have had if you knew everything in the beginning and wrote the perfect commits. That’s not really the Isabelle model.</div>
<div><br>
</div>
<div>There is a lot of benefit in recording the true history as we do in Isabelle, even if that history is less perfect.  </div>
<div><br>
</div>
<div>Cheers,</div>
<div>Gerwin<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 16 May 2025, at 13:06, Fabian Huch [isabelle-dev-bounces@mailman.proof.cit.tum.de] <forwarded_for@cse.unsw.edu.au> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div>
<p>The danger of such a model is that branches quickly become stale and a nightmare to rebase. In my experience this model only really works well if developers are well synchronized, so people work on largely distinct pieces of code, or everybody integrates
 their changes with the trunk frequently, e.g. once per day.</p>
<p>The former doesn't really apply in this environment. The latter one can already do when appropriate, since we have a trunk-based model.</p>
<p>Note that in hg, <i>branches</i> mean divergent lines of work that can't be re-based. What you describe here are
<i>topics</i> in hg.<br>
</p>
<p><br>
</p>
<p>Fabian<br>
</p>
<div class="moz-cite-prefix">On 5/16/25 12:34, Lawrence Paulson via isabelle-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:98F13930-4A94-4076-B447-C59B8CCF6736@cam.ac.uk">
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">One thing I've noticed at Amazon is that they insist on a single threaded revision trail. They do this by requiring everybody to make their changes within a personal branch, which they then re-base to the main branch before pushing. Sometimes
 they also merge adjacent commits. In return for mastering a couple of extra commands, everybody benefits from a much cleaner revision history. Do we want to try this?<br>
<br>
Larry<br>
</div>
</span></font></div>
<div><span id="cid:part1.brQ46jJf.S5q8Q5Sx@in.tum.de"><hg.jpeg></span> </div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>