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

Re: The fetch command should "always" honor remote.<name>.fetch

From
LDLewis Diamond <me@lewisdiamond.com>
Date
Apr 7, 2014, 18:46 UTC
Message-ID
<CAHwd=G=zV97H7eEK5dJ0XrfbF0bpZD6-YOvk0O8nVuqMGSz=jw@mail.gmail.com>
In-Reply-To
<xmqqioqlm21y.fsf@gitster.dls.corp.google.com>
On Mon, Apr 7, 2014 at 2:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> Lewis Diamond <git@lewisdiamond.com> writes:
>
>> 'git fetch foo develop' would result in:
>> fatal: Couldn't find remote ref test2 //Not OK, (case 1)
>
> I have no idea where the "test2" comes from, as it does not appear
> anywhere in the above write-up, and it could be a bug.
>
Sorry, "test2" was a local test to copy the error message. It should read "foo".
Show 6 quoted lines
>> 'git fetch foo master' would result in (FETCH_HEAD omitted):
>> [new ref] refs/heads/master -> foo/master //OK, but missing another
>> ref! (case 2)
>> //It should also fetch refs/users/bob/heads/master -> foo/bob/master
>
> This is an incorrect expectation.

Indeed this is the "correct" behaviour since it works as designed. However, this behaviour is inconsistent with the push command. An expectation is never "incorrect" as we are talking about intuitive vs non-intuitive.

Show 7 quoted lines
>
> The user who gave the command line said only "master", and did not
> want to grab "users/bob/heads/master".  If the user wanted to get it
> as well, the command line would have said so, e.g.
>
>         git fetch there master users/bob/heads/master
>

Actually, the user specifically configured the remote to fetch refs/users/bob/heads/*, meaning "those are the branches I'm interested in".

Show 10 quoted lines
>> If you remove this configuration line: fetch =
>> +refs/heads/*:refs/remotes/foo/*
>> Then you run 'git fetch foo master', this would result in:
>>  * branch master -> FETCH_HEAD //Debatable whether this is OK or not,
>> but it's definitely missing bob's master! (case 3)
>
> Likewise.
>
> The 'master' short-hand is designed not to match refs/users/any/thing.
>

Sure, this shorthand is designed to match refs listed in the rev parse rules list. However, a quick survey showed me that most people would expect their configuration to be honoured when using the shorthand for fetching (like it is for push). This thread is about improving the fetch command so that the short-hand works in such cases (and make it consistent with what push does).

Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 6 in “The fetch command should "always" honor remote.<name>.fetch”
  1. Lewis DiamondApr 5, 2014
  2. Junio C HamanoApr 7, 2014
  3. Lewis DiamondApr 7, 2014
  4. Junio C HamanoApr 9, 2014
  5. Lewis DiamondApr 9, 2014
  6. Junio C HamanoApr 9, 2014

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.