git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: Current Issues #3
Date: Tue, 23 May 2006 23:58:15 +0200	[thread overview]
Message-ID: <e500hd$vpr$1@sea.gmane.org> (raw)
In-Reply-To: Pine.LNX.4.64.0605220216310.3697@g5.osdl.org

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 <repo>"
     (i.e. re-clone)
>       fetch all remotes that use <repo>. 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 <remote>"
> 
>       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 <repo> <branchname>"
> 
>       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 <repo> 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 <repo> <src>:<dst>"
> 
>       same as now. fetch <repo> <src> into <dst>, 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 <repo> annd <remote> names should be unique
(to know if we use "git pull <repo>" or "git pull <remote>").

Perhaps it would be nice to have

 - "git pull <repo> *:<dst>"
 - "git pull <repo> <src>:*"
 - "git pull <repo> *:*"
and
 - "git pull <repo> <src>:<dst>:<to-merge>"

as easier to remember options. Of course what is the remote branch related
to <dst>, and what is local branch related to <src> would be in
branch/remotes/repos configuration.

BTW. what about --use-separate-remotes option support?

-- 
Jakub Narebski
Warsaw, Poland

  parent reply	other threads:[~2006-05-23 21:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-22  8:44 Current Issues #3 Junio C Hamano
2006-05-22 10:18 ` Linus Torvalds
     [not found]   ` <20060522071929.0be8d026.seanlkml@sympatico.ca>
2006-05-22 11:19     ` Sean
2006-05-23 21:58   ` Jakub Narebski [this message]
2006-05-22 10:20 ` Martin Waitz
2006-05-22 21:54 ` Daniel Barkalow
2006-05-22 22:02   ` Carl Worth
2006-05-22 23:12   ` Shawn Pearce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='e500hd$vpr$1@sea.gmane.org' \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).