Re: proposal for how to share other refs as part of refs/tracking/*

> Hi,
> 
> There's no actual code yet, (forgive me), but I've been thinking back
> to a while ago about attempting to find a way to share things like
> refs/notes, and similar refs which are usually not shared across a
> remote.
> 
> By default, those refs are not propagated when you do a push or a
> pull, and this makes using them in any project which has more then one
> repository quite difficult.
> 
> I'm going to focus the discussion primarily on refs/notes as this is
> what I am most interested in, but I think similar issues exist for
> refs/grafts and refs/replace, and maybe other sources?

> For branches, we already have a system to share the status of remote
> branches, called "refs/remotes/<remote-name>/<branch-name>"
> 
> This hierarchy unfortunately does not keep space for non-branches,
> because you can't simply add a "refs/remotes/notes/<>" or
> "refs/remotes/<name>/notes" to this as it would be ambiguous.
> 
> Now, you might just decide to push the refs/notes directly, ie:
> 
> git push origin refs/notes/...:refs/notes/...
> 
> Unfortunately, this has problems because it leaves no standard way to
> distinguish your local work from what is on the remote, so you can't
> easily merge the remote work into yours.

> For example, if Alice creates a new note and pushes it, then Bob
> creates a different note on the same commit, he needs to be able to
> merge Alice's changes into his note, just like one would do when two
> people commit to the same branch.
> 
> Today, he must pull the remote notes into a separate location, (since
> pulling directly into refs/notes will overwrite his work), and then
> update, and then push.
> 
> Because this is not standardized, it becomes unwieldy to actually
> perform on a day to day basis.
> 
> I propose that we add a new "refs/tracking" hierarchy which will be
> used to track these type of refs
> 
> We could even (long term) migrate refs/remotes into refs/tracking
> instead, or provide both with the refs/remotes being pointers or
> something like that..
> 
> Essentially, refs/notes would be pulled into
> refs/tracking/<remote>/notes/* or something along these lines.
> 
> Then, git notes would be modified to be able to have commands to
> "pull" and "push" notes which would fetch the remote, and then attempt
> a merge into the local notes, while a push would update the remote.
> 
> I chose "tracking" because it sort of fits the concept and does not
> include things like "remote-notes" or "remotes-v2" which are a bit
> weird.
> 
> I'm posting this on the mailing list prior to having code because I
> wanted to get a sense of how people felt about the question and
> whether others still felt it was an issue.
> 
> Essentially the goal is to standardize how any refs namespace can be
> shared in such a way that local copies can tell what the remote had at
> a fetch time, in order to allow easier handling of conflicts between
> local and remote changes, just like we do for branches (heads) but
> generalized so that other refs namespaces can get the same ability to
> handle conflicts.
> 
> Thanks,
> Jake
>