On Mon, Apr 7, 2014 at 2:23 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Lewis Diamond <g...@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".
>> '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
> 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
>> If you remove this configuration line: fetch =
>> 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)
> 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).
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