Junio C Hamano <gits...@pobox.com> writes: >> That wouldn't make the commands really easier to type IMHO, as you would >> still have to pull at some point, so it's: >> >> git remote add main http://example.com/project-main-repo >> git pull --set-upstream main master >> >> Vs >> >> git remote add --set-upstream master main >> http://example.com/project-main-repo >> git pull >> >> The second is a bit shorter (saves the second instance of "master"), but >> I tend to prefer the first to avoid the overly long "git remote add" >> command. > > I do not particularly care about five extra keystrokes. The reason > I prefer the latter more is conceptual clarity of it saying "I use > 'remote' to set things up, and then use 'pull' to get updated" (as > opposed to "I use 'remote' to set things half-way up, and then use > the first 'pull' to finish setting things up and getting updated. > I should remember that I do not need to give --set-upstream to later > 'pull' I used to get further updates").
That's a good argument to add a similar feature to "git remote", and it's a good idea for a microproject in the future actually. I admit I didn't consider this possibility before this discussion, thanks. I think I'll still appreciate having the possibility to "pull --set-upstream" too: * "git remote add" is ran once for a remote, "git pull --set-upstream" can be run several times for several branches. * In practice, even when "remote add" supports "--set-upstream", I'll very likely forget it, and by the time I run "git pull", it'll be too late to add --set-upstream to my "remote add" command. -- Matthieu Moy https://matthieu-moy.fr/
