Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

[Jacob Keller <jacob.keller@gmail.com>]

On Fri, Jun 23, 2017 at 6:52 AM, Jacob Keller <jacob.e.keller@intel.com> wrote:
> From: Jacob Keller <jacob.keller@gmail.com>
>
> Historically, git has tracked the status of remote branches (heads) in
> refs/remotes/<name>/*. This is necessary and useful as it allows users
> to track the difference between their local work and the last known
> status of the remote work.
>
> Unfortunately this hierarchy is limited in that it only tracks branches.
> Additionally, it is not feasible to extend it directly, because the
> layout would become ambiguous. For example, if a user happened to have
> a local branch named "notes" it could be confusing if you tried to add
> "refs/remotes/origin/notes/<remote notes refs" as this would collide
> with the already existing refs/remotes/origin/notes branch that existed.
>
> Instead, lets add support for a new refs/tracking/* hierarchy which is
> laid out in such a way to avoid this inconsistency. All refs in
> "refs/tracking/<remote>/*" will include the complete ref, such that
> dropping the "tracking/<remote>" part will give the exact ref name as it
> is found in the upstream. Thus, we can track any ref here by simply
> fetching it into refs/tracking/<remote>/*.
>
> Add support to tell a new remote to start tracking remote hierarchies
> via "--follow" which will track all refs under that section, ie:
>
> git remote add --follow notes origin <url> will cause
>
> +refs/notes/*:refs/tracking/origin/notes/* to be added as a fetch
> refspec for this remote.
>
> This ensures that any future refs which want a method of sharing the
> current remote status separate from local status could use
> refs/tracking
>
> A long term goal might be to deprecate refs/remotes/ in favor of
> refs/tracking (possibly adding in magic to convert refs/remotes directly
> into refs/tracking so that old stuff still works?).
>
> Things not yet thought through:
>
> 1) maybe we should create a configurable default so that some known set
>    of default refs get pulled (ie: notes, grafts, replace, etc?)
>    Possibly with some sort of easy way to add or subtract from the list
>    in config...
>
> 2) so far, there's no work done to figure out how to remove
>    refs/tracking when a remote is dropped. I *think* we can just delete
>    all refs under refs/tracking/<name> but I'm not completely certain
>
> 3) adding magic to complete refs under tracking, such as for git-notes
>    or similar may wish to understand shorthand for referencing the
>    remote version of notes
>
> 4) adding support for clone.. (this is weird because git-clone and
>    git-remote don't both use the same flow for setup.. oops??)
>
> 5) tests, documentation etc. (This is primarily an RFC, with the goal of
>    providing a known location for remote references such as notes to
>    reside)
>
> 6) we probably want to enable notes and grafts and other similar things
>    to use the remote tracking data if its available.
>
> 7) what about tags? Currently we fetch all tags into refs/tags directly,
>    which is a bit awkward, if for example you create a local tag and
>    a remote creates a tag with the same name, you simply don't get that
>    new version. This is good, but now you have no idea how to tell if
>    your tags are out of date or not. refs/tracking can partially resolve
>    this since remote tags will always be "exactly" what the remote has.
>    Unfortunately, I don't know how we'd resolve them into local tags...
>

Oops:

8) if we decided to go with "all refs always get tracked in
refs/tracking" we probably want to either add a way to say "all refs
except refs/tracking ones" or we want a way for servers to (by
default) not advertise refs/tracking when clients fetch from them.
That's partially why I went with the easier "only some hierarchies
will get pulled by default" Otherwise, two remotes that fetch from
each other could create a never ending cycle of
refs/tracking/origin/tracking/origin/tracking/origin/ adding a new
layer every time they fetched.

Thanks,
Jake