From: Linus Torvalds <torvalds@osdl.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] fetch/pull: support Cogito-style remote branch information.
Date: Fri, 15 Jul 2005 15:42:42 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0507151529590.19183@g5.osdl.org> (raw)
In-Reply-To: <7voe93rbmu.fsf_-_@assigned-by-dhcp.cox.net>
Hmm..
This patch actually brings up two different issues
- I actually prefer code and documentation to be separated. Finding the
actual changes to code in this patch is made much harder by the fact
that most of the changes are documentation updates. In many ways it
would have been nicer to separate the two out - first the actual
change, then the docs updates.
Maybe that's just me.
- 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.
Now, I'd like the address rewriting to actually be fairly capable, so it
should be a script of its own.
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
which I have to write out in full (or, more commonly, cut-and-paste) right
now.
Hmm?
Linus
next prev parent reply other threads:[~2005-07-15 22:43 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 [this message]
2005-07-15 23:12 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0507151529590.19183@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).