Feature request: flagging “volatile” branches for integration/development

(Thanks to Josh Triplett[*] for contributing to this message)

Hi,

We often work with development/integration branches that regularly
rebase, in addition to stable branches that do not. Git is used to share
two different types of branches:
  1. Pull requests and merged code with final SHA1s
  2. Work in progress with volatile SHA1s.

We’d like to have a consistent way to distinguish these two types by advertising a branch as “volatile”. Such a branch supports shared development on work-in-progress code (not yet ready to merge, or still being emailed as PATCHv{2,3,4,...}), or an integration/testing branch for a combination of such development branches. Branch naming conventions could help a bit here, but a large and varied set of naming conventions already exist, none of which provide machine-readable information that git itself can rely on. So the only thing available is tribal knowledge or out-of-band documentation at best, e.g.: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html

Such a “volatile” flag would instantly warn that code is not ready to re-use: https://www.chromium.org/chromium-os/chromiumos-design-docs/upstream-first

Another common issue with volatile branches is their commits being misunderstood as immutable and then their transient, top SHA1 being reported as bogus and unusable version control information in bugs (on a non-volatile branch, a single SHA1 captures the entire and exact snapshot and history).

Humans would be the initial consumers of this flag but I can imagine git itself also using it. For instance, cherry-pick could have a “smart” setting for -x, that doesn’t bother recording transient commit hashes. A merge could print an optional warning when pulling in changes from a volatile branch, and a rebase could similarly print a warning when rebasing on top of such a branch. A git server could be configured to treat non-fast forward forced pushes differently depending on the “volatility” of the target branch. A fancy user interface could color volatile SHA1s differently to discourage copy/paste. Etc.

Maybe this has already been discussed (or implemented even), and I couldn’t find the right search keywords; in this case please help me cut this discussion short. We’d appreciate any feedback you might have, either on the idea itself, or on other ways to solve the same problem.

[ ] “send patches” [ ] use some other existing mechanism to solve this [ ] will never work because of X and Y; don’t even bother