On Fri, May 17, 2013 at 10:18 PM, Felipe Contreras <felipe.contre...@gmail.com> wrote: > When the user has an upstream branch configured to track a remote > tracking branch: > > % git checkout --set-upstream-to github/master > > Doing a 'git fetch' without any arguments would try to fetch 'github', > because it's configured as current branch's remote > (branch.<current>.remote). > > However, if we do something slightly different: > > % git checkout --set-upstream-to master > > Doing a 'git fetch' without any arguments would try to fetch the remote > '.', for the same reason. > > But, unlike the in the first instance, the second command would not > update any remote tracking branch, in fact, it would not update any > branch at all. The only effect is that it would update FETCH_HEAD. > > FETCH_HEAD is a special symbol that is used to store the result of a > fetch. It can be used by other commands of git, specially 'git merge'. > > It is however, barely mentioned in the documentation, and can be > considered a plumbing concept at best, that few Git users would benefit > from using, and indeed, quite likely very few use it, or are even aware > of it. > > So when the user is presented with a message like this: > > % git fetch > From . > * branch master -> FETCH_HEAD > > The vast majority of them would have absolutely no idea what's going on. > Many of them would probably just shrug, and manually specify the remote > the want to fetch from, which is 'origin' in many cases.
s/the/they/ > If the user has say, twenty branches, ten with a local upstream > (branch.<name>.remote = '.'), and ten without an upstream. The user > might get used to typing 'git fetch' and expect Git to fetch from > 'origin' which would happen 50% of the time, but the other 50%, the user > would be forced to specify the remote. > > This inconsistency would be simply one more to join the list of > incomprehensible quirks the user has to put up when using Git, so quite s/up/up with/ > likely (s)he simply gets used to it, only to complain later in forums or > social media, outside of the dwelling distance of the typical Git > developer. > > But we can do better. > > We can add a new 'fetch.default' configuration variable (one more to > join the many necessary to force Git to behave in sane manner), so the > user can specify what (s)he wants to be performed when the remote is not > specified in the 'git fetch' command. > > This configuration would probably be welcome by 99% of the user > population, who have no clue what FETCH_HEAD is, and do set local > upstream branches, only to find out weird inconsistent behavior > depending on which branch the happen to be sitting at. s/the/they/ > We add documentation and testing as expected, and also introduce other > changes necessary to make the configuration enter into effect when it's > needed. > > The default (FETCH_DEFAULT_UNSPECIFIED), allows the current behavior to > be unmodified, so remote_get(NULL) is called, and the current rules to > determine the default branch remain. > > The new option "simple" allows Git to always fetch from "origin", which > is what most users would expect, and it's 100% consistent. > > Alternatively, the user can manually specify the current behavior with > "current" (alluding to the current branch), so that the behavior changes > depending on which branch the user happens to be sitting at. This would > allow the user to retain this behavior, if (s)he so wishes, > in case Git developers regain their sense and set a default that most > users would appreciate ("simple"). > > If the user wants, for whatever strange reason swimming in his/her head, > (s) can still fetch from a local ('.') remote (even stating that as an s/(s)/(s)he/ > English sentence doesn't make any sense). > > % git fetch . > From . > * branch master -> FETCH_HEAD > > And to any number of weird hacks with FETCH_HEAD. > > The average user lucky enough to find the 'fetch.default' configuration, > however, would never have to enter the word of "local remote" > strangeness, and would remain comfortably in the place where locals are > locals, and remotes are remotes, and 'git fetch' is always consistent, > and always does something useful. > > Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com> -- 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