On Mon, Apr 7, 2014 at 2:23 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Lewis Diamond <git@xxxxxxxxxxxxxxxx> 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 non-intuitive. > > 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". >> 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html