Re: [PATCH 0/7] Make "$remote/$branch" work with unconventional refspecs

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2013, 19:02 UTC
Message-ID: <7v8v3tuu6i.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALKQrgdp9DVDBLNwCAmQHbEfZDvhdsmSW3sh1BRo1XEnyqPPaA@mail.gmail.com>

Johan Herland <johan@herland.net> writes:

Show 12 quoted lines

> 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.

Show 11 quoted lines

>> 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.