Fossil
Fossil
Posted Oct 22, 2021 10:56 UTC (Fri) by farnz (subscriber, #17727)In reply to: Fossil by marcH
Parent article: How Red Hat uses GitLab for kernel development
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.
Posted Oct 22, 2021 20:56 UTC (Fri)
by flussence (guest, #85566)
[Link]
Posted Oct 25, 2021 0:41 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
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
Fossil
git "volatile" branches
> ...
> The ability to share the mutable history is useful in some cases, ...