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 09:28:31 -0700 Message-ID: <87fy6o770w.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> <87k5w07dft.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_09:28:25_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Junio C Hamano , Marcin Kasperski , git@vger.kernel.org To: Linus Torvalds X-From: git-owner@vger.kernel.org Wed Apr 25 18:28:46 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 1HgkMF-0002uE-Ph for gcvg-git@gmane.org; Wed, 25 Apr 2007 18:28:44 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752387AbXDYQ2k (ORCPT ); Wed, 25 Apr 2007 12:28:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752985AbXDYQ2k (ORCPT ); Wed, 25 Apr 2007 12:28:40 -0400 Received: from theworths.org ([217.160.253.102]:49392 "EHLO theworths.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752387AbXDYQ2j (ORCPT ); Wed, 25 Apr 2007 12:28:39 -0400 Received: (qmail 12830 invoked from network); 25 Apr 2007 12:28:31 -0400 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 25 Apr 2007 12:28:31 -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_09:28:25_2007-1 Content-Type: text/plain; charset=US-ASCII On Wed, 25 Apr 2007 07:55:49 -0700 (PDT), Linus Torvalds wrote: > Alternatively, we *could* make just > > git checkout --track branch > > be a shorthand for > > git checkout --track -b branch origin/branch > > when "branch" doesn't exist, but origin/branch does. With the "--track", > it's already unambiguous (you cannot track a detached head, so we know we > want a branch. I like that a lot, thanks! Things that make the command-line simpler with no loss in functionality nor introducing any ambiguity are really nice. And I'd even follow that up to propose making "git checkout branch" (where branch doesn't exist but remote//branch does), do something new, (not detached head, nor creating a local tracking branch), that would allow the following: 1. Using "git checkout branch" to examine the working-tree status of a branch. This functionality exists already, but with a fairly obnoxious detached head warning. 2. Subsequently using "git pull" to track that remote branch This functionality is currently missing without creating a local branch first. This is an inconvenience compared to the pre-separate-remotes git where "git checkout next" followed by a sequence of "git pull" was enough to track a branch. Now, old git also had the huge defect that it was too easy to screw everything up by committing to what should have been treated as a read-only tracking branch, which is where the next point comes in. 3. Allow a commit from this state, by *then* creating the explicit local branch setup to track the remote-tracking branch. That is, under this proposal the command sequence of: git checkout branch # hack git commit Would get one to the exact same state as today's sequence of: git branch --track branch origin/branch git checkout branch # hack git commit Which to me just looks like making git easier to use. Of course, git could complain politely if the branch name it wanted to create were taken already and instruct the user how to create a new name for the tracking branch before the commit. Is that a totally insane idea? (The answer might very well depend on some details of the implementation---presumably .git/HEAD would have to store both the name of the remote-tracking branch as well as the sha1 to which it corresponded at the time of the checkout.) -Carl --pgp-sign-Multipart_Wed_Apr_25_09:28:25_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGL4Gv6JDdNq8qSWgRAs42AJ9uLL7hSqhSfUa3oNsncU49MNPmEQCeNp9i VQm9qGHKBMWViRi832JB8Lw= =v0vf -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Apr_25_09:28:25_2007-1--