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

> Jacob Keller <jacob.e.keller@intel.com> writes:
> 
>> 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>/*.
> 
> I do think this overall is a good goal to aim for wrt "tracking",
> i.e.  keeping a pristine copy of what we observed from the outside
> world.  In addition to what you listed as "undecided" below,
> however, I expect that this will highlight a lot of trouble in
> "working together", i.e. reconciling the differences of various
> world views and moving the project forward, in two orthogonal axes:
> 
>   - Things pointed at by some refs (e.g. notes/, but I think the
>     ".gitmodules equivalent that is not tied to any particular commit
>     in the superproject" Jonathan Nieder and friends advocate falls
>     into the same category) do not correspond to the working tree
>     contents, and merging their contents will always pose challenge
>     when we need to prepare for conflict resolution.

>   - Things pointed at by some other refs (e.g. tags/) do not make
>     sense to be merged.  You may locally call a commit with a tag
>     "wip", while your friends may use the same "wip" tag to point at
>     a different one.  Both are valid, and more importantly, there is
>     no point even trying to reconcile what the "wip" tag means in the
>     project globally.
> 
> For the former, I expect that merging these non-working tree
> contents will all have to require some specific tool that is
> tailored for the meaning each hierarchy has, just like "git notes
> merge" gives a solution that is very specific to the notes refs (I
> do not know how well "notes merge" works in practice, though).
> 
> For the latter, having a separate tracking hierarchy is a strict
> improvement from "tracking" point of view, but I think "working
> together" also needs a well designed set of new look-up rules, and a
> new convention.  For example, some tags may not want to be shared
> (e.g. "wip" example above) even though they should be easy to access
> by those who already have them (e.g. "git log ..wip" should work
> without having to say "git log ..refs/local-tags/wip", even if we
> decide to implement the "some tags may not want to be shared"
> segregation by introducing a new hierarchy).  And also a shared tag
> that is copied to "refs/tracking/origin/tags/v1.0" would need a way
> better than "git log tracking/origin/tags/v1.0" for this mechanism
> to be useful in everyday workflow.
> 
> Thanks.
>