"Herbert, Marc" <marc.herbert@xxxxxxxxx> writes:
>> The hard part may be policy (e.g. what if the user does not want a branch
>> to be treated volatile by various commands even if it receives such
>> flag from a git server).
>
> There would be instant, human-readable value in such a new "volatile"
> flag. Machine use and policies can be discussed later. These will be
> easier to prototype, experiment and refine once the flag exists.
We tend to avoid adding random cruft to the system whose semantics
is not well defined, so that we can avoid having to support an ill
defined feature forever.
> ... Now I bet this on the other hand must have been
> discussed (and rejected?) before, any pointer?
I suspect that people may have expressed vague wish from time to
time, but I do not think we saw a proposal that outlines the design
at a concrete enough level to let us rejecting in the past ;-)
Let me list some things that needs to be designed that comes to my
mind offhand:
* How would a user mark a ref as "volatile"? I am assuming that
anybody do so in her own local repository, but how does one mark
a ref as "volatile" at a hosting site, and who is allowed to do
so (one possibile design is "new option to 'git push' will do so,
and anybody who can push to the ref is allowed to", and I am fine
with that design, but you have to spell that out in a proposal)?
* How would a user learn if a ref is "volatile"? Does "ls-remote"
show that information?
* Does volatile-ness of a ref at the remote site propagate to your
remote-tracking ref that corresponds to it? What does it mean
that refs/remotes/origin/pu is marked as volatile in your local
repository? You cannot "checkout -b" based on it? Does "branch"
based on it need to be forbidden as well?
* Can a local ref be "volatile"? What does it mean (the same
subquestions as above)?
* If your local branch myA is set to build on a remote-tracking
branch A and push back to branch A at the remote, i.e.
$ git checkout -t -b myA refs/remotes/origin/A
$ ... work work work ...
$ git push
is set to result in their branch A updated with what you built in
myA, and if the branch A at the remote is marked as "volatile",
does it make your "myA" also "volatile"? How is the volatile-ness
inherited? From their A to your remotes/origin/A and then to
your myA? Any other useful rule that defines the propagation?
* Do we only care about "volatile"? If we are extending the system
to allow setting and propagating this new bit per ref (I am
blindly assuming that you do not have a strong reason to limit
this to branches), we may as well just design this extension to
allow the projects to assign arbitrary set of bits to refs. Some
projects may want to have different degree of volatile-ness and
have "volatile" refs, "unstable" refs and "iffy" refs, for
example.
Side note: even if we were to go with "any random label can be
assigned and the meaning for the labels can be defined by the
project convention" approach, it does not necessarily mean we are
adding a random cruft whose semantics is ill-defined. "Git does
not do anything special to a ref based on what labels it has--it
just remembers what labels the user told it to attach to the ref,
and shows what labels the ref has when asked" can be very well
defined semantics.