From: Jakub Narebski Date: Tue, 23 May 2006 21:58:15 GMT Subject: Re: Current Issues #3 Message-ID: In-Reply-To: Linus Torvalds wrote: [...] > But with the above, you can fairly naturally do: > > - "git pull" > > No arguments. fetch the remote described by the current branch, > and merge into current branch (we might decide to fetch all the > remotes associated with that repo, just because once we do this, > we might as well, but that's not that important to the end > result). > > - "git pull " (i.e. re-clone) > fetch all remotes that use . IFF the current branch is > matched to one of those remotes, merge the changes into the > current branch. But if you happened to be on another unrelated > branch, nothing happens aside from the fetch. > > - "git pull " > > fetch just the named remote. IFF that remote is also the remote > for the current branch, do merge it into current. Again, we > _might_ decide to just do the whole repo. > > - "git pull " > > fetch the named branch from the named repository and merge it into > current (no ifs, buts or maybes - now we've basically overridden > the default relationships, so now the is just a pure > shorthand for the location of the repository) Fetch into curret branch, or specified by branch configuration, then current if unspecified? > - "git pull :" > > same as now. fetch into , and merge it into the > current branch (again, we've overridden any default relationships). > > but maybe this is overdesigned. Comments? It all means that within annd names should be unique (to know if we use "git pull " or "git pull "). Perhaps it would be nice to have - "git pull *:" - "git pull :*" - "git pull *:*" and - "git pull ::" as easier to remember options. Of course what is the remote branch related to , and what is local branch related to would be in branch/remotes/repos configuration. BTW. what about --use-separate-remotes option support? -- Jakub Narebski Warsaw, Poland