Johan Herland <jo...@herland.net> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html