Fossil

Posted Oct 21, 2021 22:36 UTC (Thu) by marcH (subscriber, #57642)
In reply to: How Red Hat uses GitLab for kernel development by fung1
Parent article: How Red Hat uses GitLab for kernel development

Interesting, thanks!

Also realized I forgot to mention Fossil:
https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-gi...
"One way to describe Fossil is that it is "GitHub-in-a-box."

That's probably because I never used it and also because I violently disagree with the lack of history rewriting:

> When every commit is pushed to the parent repo by default, it encourages a working style in which every commit is tested first. It encourages thinking before acting. We believe this is an inherently good thing.

Very ironic considering I use git rebase -i to _test_ a variety of "what if" scenarios every single day.

I find the rest of the page very impressive.

Fossil

Posted Oct 22, 2021 10:56 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

There's arguably two separate sets of workflows you want out of your SCM:

Immutable shared history, showing how the product developed. This is curated by the committers to tell a story about the code.
Mutable private history, where you're checkpointing your work in interesting places so that nothing of interest is lost when you try something out. You will later rebase and restack this to become the immutable shared history you push.

The ability to share the mutable history is useful in some cases, but to do it well adds a lot of complexity (see Mercurial's "Changeset Evolution" extension). But the ability to work locally and store up commits of random changes, then to build and test the final history you wish to push, is extremely useful.

Fossil

Posted Oct 22, 2021 20:56 UTC (Fri) by flussence (guest, #85566) [Link]

I'd liken it to the "preview comment" button here - that one roadbump causes me to put far more care into what I'm emitting than if there'd just been a single post button (even if it doesn't seem like it sometimes). I've used many other UIs for committing what I type to the internet, and it feels like there's a definite correlation between the overall quality of results in some of them and whether they let (or require) you experiment and make mistakes in private.

git "volatile" branches

Posted Oct 25, 2021 0:41 UTC (Mon) by marcH (subscriber, #57642) [Link]

> There's arguably two separate sets of workflows you want out of your SCM:
> ...
> The ability to share the mutable history is useful in some cases, ...

Yes it would save a lot of confusion if git provided some kind of "volatile" branch marker so publishers can share their intentions and set mutability expectations. Currently this is performed with poor branch naming conventions or worse: pure word of mouth.

Giving the distinction between 1. and 2. a name would elevate it and also clarify the recurring "don't rebase public branches" advice which is exactly what intel-next and others do all the time!? And hey, who knows it could even stop questions like "why can't I commit and push at the same time" from Fossil and other fans.

https://www.google.com/search?q=git+volatile+rebase+branches