git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] fetch/pull: support Cogito-style remote branch information.
Date: Fri, 15 Jul 2005 16:12:03 -0700	[thread overview]
Message-ID: <7v64vbpsu4.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0507151529590.19183@g5.osdl.org> (Linus Torvalds's message of "Fri, 15 Jul 2005 15:42:42 -0700 (PDT)")

Linus Torvalds <torvalds@osdl.org> writes:

>  - I actually prefer code and documentation to be separated. ...
>    first the actual change, then the docs updates.

Understood.

>  - I'd much rather have a generic "address rewriting layer" than a "-b" 
>    flag.
>
>    I don't mind the shorthand at all, but I don't think it should be that
>    special. It's not "worthy" of a flag - if you have a shorthand that 
>    says "linus == rsync://kernel.org/pub/scm/git/git.git", then I think it 
>    should just work, and 
>
> 	git pull linus
>
>    should end up not needing a "-b" flag. It's not like there is any 
>    real ambiguity.

That makes sense.  Naturally,

	git pull linus experimental
        git pull linus tag v2.6.13

should expand to:

       git pull rsync://kernel.org/pub/scm/git/git.git/ experimental
       git pull rsync://kernel.org/pub/scm/git/git.git/ tag v2.6.13

If a user is usually interested in e100 driver work, we should
allow:

	echo rsync://kernel.org/pub/.../git/jgarzik/netdev-2.6.git#e100
	        >.git/branches/jgarzik-e100

and "git pull jgarzik-e100" should expand to:

	git pull rsync://kernel.org/pub/.../netdev-2.6.git/ e100

If the user says:

	git fetch jgarzik-e100 ieee80211-wifi

because the user wanted to peek his other branch just once, but
did not want to bother creating another remote reference
("jgarzik-wifi", perhaps) for this one-time use.  This should
expand to:

	git fetch rsync://kernel.org/pub/.../netdev-2.6.git/ ieee80211-wifi

> And it's not necessarily just the branch handling, but more of a generic
> shorthand: I'd love to be able to mix something like
>
> 	git pull jgarzik/misc-2.6 upstream
>
> and "jgarzik" would be expanded (through something like .git/branches) to 
> "master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/"), resulting in the 
> _full_ path being expanded to
>
> 	master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6 upstream

Nice, and sounds doable without too much ambiguities.  This last
one, however, needs to be coordinated with Pasky, if we want to
use .git/branches/$name convention.  I think Cogito would barf
with your partial URL that ends with "...git/jgarzik/".

I'll code something up.

  reply	other threads:[~2005-07-15 23:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-14  7:08 [PATCH] Documentation: packed GIT support commands Junio C Hamano
2005-07-15  7:59 ` [PATCH] Documentation: update tutorial to talk about push Junio C Hamano
2005-07-15 18:40   ` [PATCH] Documentation: pull, push, packing repository and working with others Junio C Hamano
2005-07-15 21:40   ` [PATCH] fetch/pull: support Cogito-style remote branch information Junio C Hamano
2005-07-15 22:42     ` Linus Torvalds
2005-07-15 23:12       ` Junio C Hamano [this message]
2005-07-16  7:16       ` [PATCH] fetch/pull: short-hand notation for remote repositories Junio C Hamano
2005-07-16 16:47         ` [PATCH-fix] " Junio C Hamano
2005-07-16 17:33           ` Linus Torvalds
2005-07-16 17:52             ` Junio C Hamano
2005-07-18 17:28             ` [PATCH] git-clone-script: store where we cloned from in .git/branches/origin Junio C Hamano
2005-07-18 17:29             ` [PATCH] tutorial: mention "git clone" records .git/branches/origin Junio C Hamano
2005-07-16  7:17       ` [PATCH] Documentation: describe short-hand used in fetch/pull Junio C Hamano
2005-07-16  3:54     ` [PATCH] Documentation: adjust cvsimport command line Junio C Hamano

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=7v64vbpsu4.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=torvalds@osdl.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).