git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Fwd: Errors when diff'ing arbitrary upstream remotes are not intuitive if git pull --all hasn't been done

From
Jeff King <peff@peff.net>
Date
Oct 25, 2013, 07:10 UTC
Message-ID
<20131025071048.GA16856@sigill.intra.peff.net>
In-Reply-To
<CALKQrgc0u8TA4mXc+2Hv+Fyo8EYNuiickF_janeCxkzFn+xAvA@mail.gmail.com>
On Fri, Oct 25, 2013 at 09:03:41AM +0200, Johan Herland wrote:
Show 12 quoted lines
> Actually, I don't think there's much refspec stuff to be done here.
> When running "git diff $remote/$branch", there are 3 possible
> outcomes:
> 
>  - $remote is not a valid remote name, the user probably meant
> something different (like "nested/branch"). The current error message
> is fine.
> 
>  - $remote is a valid remote name, but $branch has not (yet) been
> fetched from there. Suggest the user run "git fetch $remote"
> 
>  - $remote/$branch is a valid remote-tracking branch. The diff works! No errors.
Right, I think it is the second case we are talking about.
Show 9 quoted lines
> So, AFAICS, the patch should simply:
> 
>  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.

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.

-Peff
Previous: Johan HerlandNext: Johan Herland
Message 5 of 6 in “Fwd: Errors when diff'ing arbitrary upstream remotes are not intuitive if git pull --all hasn't been done”
  1. yaneurabeya .Oct 24, 2013
  2. Jeff KingOct 25, 2013
  3. Jeff KingOct 25, 2013
  4. Johan HerlandOct 25, 2013
  5. Jeff KingOct 25, 2013
  6. Johan HerlandOct 25, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.