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

From: Herbert, Marc <marc.herbert@intel.com>
Date: Feb 15, 2017, 00:13 UTC
Message-ID: <6c7cb3da-714b-87ed-5885-220a433c646f@intel.com>
In-Reply-To: <CACsJy8A5AXs5jQUQAdb=tuBzWYKNbu5DPnQ88DXott8ht61egA@mail.gmail.com>

[apologies for the accidental "smart" quotes and the resulting UTF8 encoding of the subject]

On 04/02/2017 06:01, Duy Nguyen wrote:

Show 5 quoted lines

> 
> 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