On 2017-06-23 04:54 PM, Junio C Hamano wrote:
Jacob Keller <jacob.e.kel...@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.
OTOH, we shouldn't need to do any conflict resolution on these
"tracking" refs: The remote side should update the refs properly.
Nobody should make local changes to these refs.
I guess I'm advocating that git should only allow "tracking" refs to be
updated by a fetch, or a successful push of a local, non-"tracking" ref.
M.
- 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.
