[apologies for the accidental "smart" quotes and the resulting UTF8 encoding of the subject] On 04/02/2017 06:01, Duy Nguyen wrote: > > But that would be local information only. We don't have ways to > transfer branch metadata (and we definitely don't want to just share > .git/config file with everybody). I suppose extending git protocol for > this is not hard (e.g. appending metadata in the "have" lines). Thanks Duy. So did you mean: [ X ] send (big!) patches ? > 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. ---- Interestingly, it was pointed to me (thanks Calvin) that GitLab has implemented this volatile flag exactly. It's called... "work in progress": https://docs.gitlab.com/ee/user/project/merge_requests/work_in_progress_merge_requests.html I'm not familiar with GitHub, however browsing its documentation the (in)existence of a pull request seems equivalent to a (non-)volatile flag. Just like a pull request by email without the need to find and search a mailing-list. I'm familiar with Gerrit and there's no strict equivalent to a volatile flag, however it's: - totally obvious when the commit has been accepted and merged - hence its SHA1 final. - usually fairly clear whether the code is still WIP or near the "pull request" stage based on: how the code review is going, approvals and other metadata. Long story short: to integrate code reviews and source control these systems overload git with a ton of metadata so it's no surprise to always find in them something that more or less looks like a "volatile" flag. I guess this leads to the more general question of core git possibly implementing some generic metadata/property system (key,value pairs? everything is a ref?) to better support code review and other git-based software... Now I bet this on the other hand must have been discussed (and rejected?) before, any pointer? Marc