Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > > But then they later wonder why they need `git pull origin branch` > > to merge in branch, when they usually just say `git pull`. What is > > the need for that funny keyword `origin`? Why do I have to say > > where to get the branch from sometimes and not others? > > What's the constructive suggestion for improvement we can draw from this > after all? Should we deprecate the defaulting of "origin" so that > everybody now should always say "git pull $where"? Yes, I think that is what I was thinking. By making users always say where they are pulling, fetching or pushing from/to it becomes less weird when you have to give a refspec too. But this clearly harms the `git pull` case that relies upon the magic branch.$name.remote and branch.$name.merge keys, as now git-pull is expecting the user to supply a remote name, but one was already saved for this current branch. It also clearly harms people who have only origin and want to grab updates from there with just `git fetch` or `git pull`. Such a change would be asking these users to enter a longer command line. On the other hand, I think it would teach those users how to better make use of git, and may cause less questions when they have to step slightly outside of their normal use case and specify a refspec. > In other words, make > people more aware that what _they_ do is the special case to have only one > remote to interact with? My special case is always the other guys' common case. You can't please everone. But here I think that _our_ special case (where we always give the remote name/URL to fetch/pull/push) helps users to learn the tool better, because it erases a special case from their vocabularly of Git commands. -- Shawn. -- 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
