From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument) Date: Wed, 25 Apr 2007 13:29:19 -0700 Message-ID: <873b2o6vvk.wl%cworth@cworth.org> References: <20070417104520.GB4946@moonlight.home> <8b65902a0704170841q64fe0828mdefe78963394a616@mail.gmail.com> <200704171818.28256.andyparkins@gmail.com> <20070417173007.GV2229@spearce.org> <462521C7.2050103@softax.com.pl> <4627ABBB.8060709@softax.com.pl> <877is29b1l.wl%cworth@cworth.org> <7vps5ud91x.fsf@assigned-by-dhcp.cox.net> <87vefm7l6g.wl%cworth@cworth.org> <7v1wiabbfr.fsf@assigned-by-dhcp.cox.net> <87mz0w7g3j.wl%cworth@cworth.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Apr_25_13:29:19_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Junio C Hamano , Linus Torvalds , Marcin Kasperski , git@vger.kernel.org To: Daniel Barkalow X-From: git-owner@vger.kernel.org Wed Apr 25 22:29:57 2007 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1Hgo7f-0003a6-U9 for gcvg-git@gmane.org; Wed, 25 Apr 2007 22:29:56 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2993097AbXDYU3n (ORCPT ); Wed, 25 Apr 2007 16:29:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S2993102AbXDYU3m (ORCPT ); Wed, 25 Apr 2007 16:29:42 -0400 Received: from theworths.org ([217.160.253.102]:51339 "EHLO theworths.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993097AbXDYU3e (ORCPT ); Wed, 25 Apr 2007 16:29:34 -0400 Received: (qmail 15572 invoked from network); 25 Apr 2007 16:29:20 -0400 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 25 Apr 2007 16:29:20 -0400 In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: --pgp-sign-Multipart_Wed_Apr_25_13:29:19_2007-1 Content-Type: text/plain; charset=US-ASCII On Wed, 25 Apr 2007 15:44:11 -0400 (EDT), Daniel Barkalow wrote: > Linus has stated a preference on the lkml for being told about branches in > the syntax used for anonymous pulls: URL branchname. That's a fine syntax too. > Now, this syntax isn't available for git-clone, because git-clone puts the > optional directory to create after the URL. But, in an ideal world, this > is how it would work; you could see a pull request, and just type "git > some-command ". Yes. That's exactly what I'm talking about, being able to very easily just paste the branch specifier to a git command. And yes, it would be convenient if one could do this for as many commands as possible. The fact that git-clone can't accept this syntax is unfortunate, (and maybe that is the only reason I was inclined to add the '#' character). > Here, you probably need to specify what you want the new branch to be, > because it will often be the case that the remote branch will be "master" > in a repository with a long unrecognizable URL, and you need to be able to > switch to and away from the branch in some sane way. On the other hand, > the user will presumably never care too deeply about the remote, aside > from that git remembers stuff appropriately. I say, use the hash of the > URL as the name of the remote, and provide some shorthand for the tracking > branch that would be merged by default into the current head, and you're > set. I.e.: > > git track new-name URL [branch] OK, that still allows for pasting the URL and branch, but the user has to know not only "git track" but also that she must invent a local for the branch and insert that into the command as well. And it's hard for me to help the user on this point (at least in a cut-and-pasteable way), since the whole point of that argument is to create an entry in a private namespace that I don't know anything about. How about making that optional at least? That is create a local branch named for: git track URL but also allow something like: git track --as URL > creates and checks out a new branch "new-name" with the config: > > [remote "hash of URL"] > url = URL > fetch = +refs/heads/*:refs/remotes/hash of URL/* > [branch "new-name"] > remote = "hash of URL" > merge = refs/heads/[branch] Yes, this is the kind of stuff I'd like to see. Just create a remote on behalf of the user with whatever unique name you want, (or use an existing remote if one already exists for the given URL). > Incidentally, I'm not seeing the case of wanting to track multiple > branches from the same repository as nearly as likely for a novice as > wanting to track multiple branches from different repositories. Yes, I would agree with that. > With the most common case for two tracking branches being master from two > repositories, such that upstream branch names are most often useless for > distinguishing anything. Ah, that's an interesting point. It's interesting because it's obviously the case for some projects, but it's also not the case for some, (like the cairo project that I care about). Maybe we're still overly accustomed to our "central" mentality, but we don't really have a lot of interesting "master" branches in our personal repositories. Instead, the central repository has "master" and one branch for each stable maintenance series, then each developer's personal repository has a collection of topic branches for stuff that is cooking. I guess we just don't have sub-maintainers maintaining entire collections of patches with git like you get with the kernel for example. -Carl --pgp-sign-Multipart_Wed_Apr_25_13:29:19_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGL7of6JDdNq8qSWgRApAPAJ9mExra9GiNz7meegvhqaPK9v9ZKQCdFGyM 6xY1o1GayQmu3FQeLrKW/6Q= =iKYi -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Apr_25_13:29:19_2007-1--