On 11-10-17 02:34 PM, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > >> I think the exact same confusion exists. I told git to update 'next' >> from origin, but it didn't touch refs/remotes/origin/next. > > Except that you didn't tell git to *update* the remote tracking branch for > 'next'; you merely told it to fetch 'next' at the remote. > >> ... But I suspect that is not how many git users think of it. > > I am inclined to agree that it might be the case; see my other message in > this thread. Indeed. Apologies for missing that subtlety. So now I think option (2) is the best choice. To support one-off fetches, teach fetch to accept "foo:" refspecs as "fetch ref foo from the remote and only update FETCH_HEAD" -- maybe allow "foo:FETCH_HEAD" too, for folks who like to be explicit and can't remember the shorthand syntax. The rest of this post explains my reasoning, which I think pretty much just rehashes what Junio said more efficiently in his initial message. Overall I'd expect "git fetch origin next" to be a subset of "git fetch origin". That is, since the default fetch refspec is +refs/heads/*:refs/remotes/origin/* normally "git fetch origin" gets all of origin's updated refs (ff or not) and puts them under the local remotes/origin/ space. So I would expect "git fetch origin next" to only fetch the "next" ref from origin and update the local remotes/origin/next ref. Given the default fetch refspec, I'd expect "git fetch origin +next" to do the exact same thing. The + on the command line is basically redundant. But removing the + from the fetch refspec changes things. Now I'd expect plain "git fetch origin" to fail if there are any non-ff updates, and "git fetch origin next" should also fail if origin's next ref is non-ff. But "git fetch origin +next" would succeed. In all cases if the command-line refspec has no RHS then git should try to figure out which local ref to update from the config, and it should die if it can't figure out a local ref to create or update. (As I said above, maybe allow "git fetch origin foo:" to let the user put the tip of origin's foo ref into FETCH_HEAD.) All this gets a bit more complicated if the user has currently checked out the a ref that should be updated (regardless of the presence of a LHS +). But really only old-style git gurus should run in to that problem. M. -- 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