Johan Herland <johan@xxxxxxxxxxx> writes:
> I want to extend the same reasoning to remote-tracking refs, i.e.
> "$remote/$name" could be auto-completed into any of
>
> refs/remotes/$remote/$name
> refs/remotes/$remote/tags/$name
> refs/remotes/$remote/heads/$name
>
> without causing ambiguity in the common case. When there is ambiguity, we
> would resolve that in the same manner as for local refs.
>
> The current series only concerns itself with the branches, but the larger
> intention is to make it work for tags and other refs as well.
Good ;-).
So another issue that remains is the following, I think.
When interpreting $nick/$name, assuming that we can tell where $nick
for a remote ends and $name for the ref we take from the remote
begins [*1*], how would we determine which refs/remotes/$remote/ is
used for $nick?
My gut feeling is that we should ignore any "remote.$nick.fetch"
wildcard mapping, e.g.
[remote "foo"]
fetch = +refs/heads/*:refs/remotes/bar/heads/*
fetch = +refs/tags/*:refs/remotes/baz/tags/*
so that we look always in refs/remotes/$nick/ somewhere, for at
least two reasons:
* For sane people, "bar" and "baz" in the above example are both
"foo", so ignoring remote.foo.fetch mapping is a no-op for them.
* For people who deliberately wanted to move "foo"'s refs to
different hierarchies depending on the hierarchies at the origin
(i.e. branches to "bar", tags to "baz"), they wanted to do so for
a reason to group related things in "bar" (and "baz") [*2*]. For
them, mapping with remote.$nick.fetch" means not allowing them to
use the real name of the group (i.e. "bar") they chose to name
their refs.
>> If the final end result you are shooting for is to introduce an
>> extra level between the remote name and the branch names, i.e.
>> "heads/", any solution needs to at least have a plan (not necessarily
>> a detailed design or implementation) for the other hierarchies. The
>> possibility to have these other hierarchies per remote is the true
>> progress that the "heads/" at that level can give us; there is not
>> much point to have heads/ after refs/remotes/origin/, if heads/ is
>> the only thing that can come there.
>
> I fully agree. This series was meant as the first step in that direction
> (sorry for not describing my intentions more clearly).
And I do not think we mind terribly if we extend the ref_rev_parse_rules[]
used in dwim_ref() to also look at these
refs/remotes/$nick/$name
refs/remotes/$nick/tags/$name
refs/remotes/$nick/heads/$name
(the first of the above is existing "refs/remotes/%.*s"). I think
it is going too far if you extend it further to
refs/remotes/$nick/*/$name
where the code does not control what an acceptable match for '*' is
(i.e. origin/foo matching origin/changes/foo might be OK, but
matching it with origin/randomstring/foo is not, unless the canned
ref_rev_parse_rules[] knows about the "randomstring", or there is a
configuration mechanism for the user to tell us she cares about the
"randomstring" hierarchy in her project).
[Footnotes]
*1* I offhand do not remember if we even allow multi-level remote
nicks, but I do know we support multi-level branch names, so it
may turn out that the only valid split of origin/jh/rbranch is
topic 'jh/rbranch' from remote 'origin' and not topic 'rbranch'
from remote 'origin/jh'.
*2* Perhaps "bar" in the above is spelled "topics", and the
hierarchy may be used to collect non-integration single topic
branches from more than one remote. An example that is more in
line with such a usage might be:
[remote "jh"]
fetch = +refs/heads/*:refs/remotes/topics/heads/jh/*
[remote "jk"]
fetch = +refs/heads/*:refs/remotes/topics/heads/jk/*
[remote "fc"]
fetch = +refs/heads/*:refs/remotes/topics/heads/fc/*
and I would expect "git merge topics/jh/rbranch" to merge the
"refs/remotes/topics/heads/jh/rbranch" topic branch.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html