On 11-10-19 12:31 AM, Junio C Hamano wrote: > Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > >> 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.) > > I'd agree with everything you said in your message, except for the above > "it should die" part. > > You are assuming that the user knows what his configured refspecs would > normally do and that is the whole reason why "git fetch origin next" that > would update the remote tracking branch specified for the upstream's next > might feel more natural than the current behaviour. I too think that is a > reasonable assumption. > > With the same assumption, if you said "git fetch origin frotz" when you > know you are not usually tracking the remote 'frotz' branch, the command > just should store what is fetched in FETCH_HEAD (and nowhere else) without > dying. I do not think how it helps the user to die in that situation. Sounds reasonable to me. In all cases, I'd expect fetch to tell me what it did. >> 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 +). > > That "do not update the currently checked out branch" already exists and > is correctly handled by "git fetch", I think. Sweet! (I'd also be happy if fetch updated the ref, and left the checked-out HEAD detached, with attendant messages. But then I'm quite comfortable working with detached HEADs.) 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