git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: Jeff King <peff@peff.net>
Cc: "yaneurabeya ." <yanegomi@gmail.com>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: Fwd: Errors when diff'ing arbitrary upstream remotes are not intuitive if git pull --all hasn't been done
Date: Fri, 25 Oct 2013 09:25:56 +0200	[thread overview]
Message-ID: <CALKQrgdfcDzq+M4Pi=DdbSPXCDCcXRtk6qV7qhvyHviJoJXA8A@mail.gmail.com> (raw)
In-Reply-To: <20131025071048.GA16856@sigill.intra.peff.net>

On Fri, Oct 25, 2013 at 9:10 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Oct 25, 2013 at 09:03:41AM +0200, Johan Herland wrote:
>>  1. Split the input on the first '/' into $remote/$branch, and use the
>> preceding part ($remote) as a potential remote name, and the following
>> part ($branch) as a potential branch name. (Although it is
>> theoretically possible to have remote names containing slashes, I
>> don't think anybody uses them, and we have considered disallowing
>> them, mainly because of this very issue: it makes "$remote/$branch"
>> parsing (even more) ambiguous)
>
> What I specifically meant is that this breaks with a remote like:
>
>   [remote "foo"]
>     fetch = +refs/heads/*:refs/remotes/bar/*
>
> The correct advice for "bar/branch" is to recommend "git fetch foo", and
> the correct advice for "foo/branch" is nothing at all.
>
> I know such config is unusual, but I thought there was a recent push for
> us to be accurate about finding the local side of remote tracking
> branches, rather than just assuming they start with "$remote". Maybe I
> am misremembering, though; I thought it was related to potentially
> shifting the default refspecs.

Obviously, you're right. Sorry about that, haven't had my morning coffee yet. :(

> The procedure along those lines would be:
>
>   for each remote
>     for each fetch-refspec in remote
>       if refspec.rhs contains "refs/remotes/$failed_branch"
>         recommend "git fetch $remote"
>
> I was just wondering if we had something to make that "does this refspec
> contain this ref" part easier.

Yes, I found the following code in branch.c (added in 41c21f2), which
does a similar thing. Might want to refactor that into something more
general:

+static int check_tracking_branch(struct remote *remote, void *cb_data)
+{
+       char *tracking_branch = cb_data;
+       struct refspec query;
+       memset(&query, 0, sizeof(struct refspec));
+       query.dst = tracking_branch;
+       return !(remote_find_tracking(remote, &query) ||
+                prefixcmp(query.src, "refs/heads/"));
+}
+
+static int validate_remote_tracking_branch(char *ref)
+{
+       return !for_each_remote(check_tracking_branch, ref);
+}


Hope this helps,

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

      reply	other threads:[~2013-10-25  7:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAGH67wSf_RQigCmqRZKOpHdV9ELqE=078mkpwA4dfnUr=AvGVQ@mail.gmail.com>
2013-10-24 18:07 ` Fwd: Errors when diff'ing arbitrary upstream remotes are not intuitive if git pull --all hasn't been done yaneurabeya .
2013-10-25  6:14   ` Jeff King
2013-10-25  6:14     ` Jeff King
2013-10-25  7:03       ` Johan Herland
2013-10-25  7:10         ` Jeff King
2013-10-25  7:25           ` Johan Herland [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALKQrgdfcDzq+M4Pi=DdbSPXCDCcXRtk6qV7qhvyHviJoJXA8A@mail.gmail.com' \
    --to=johan@herland.net \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=yanegomi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).