From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: several quick questions Date: Tue, 14 Feb 2006 12:10:28 -0800 Message-ID: <87fymlvgzv.wl%cworth@cworth.org> References: <43F20532.5000609@iaglans.de> <87k6bxvmj6.wl%cworth@cworth.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Feb_14_12:10:23_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: "Nicolas Vilz 'niv'" , git X-From: git-owner@vger.kernel.org Tue Feb 14 21:13:04 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F96Xi-0003PS-Fx for gcvg-git@gmane.org; Tue, 14 Feb 2006 21:12:58 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422689AbWBNUMz (ORCPT ); Tue, 14 Feb 2006 15:12:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1422767AbWBNUMz (ORCPT ); Tue, 14 Feb 2006 15:12:55 -0500 Received: from theworths.org ([217.160.253.102]:34510 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1422689AbWBNUMy (ORCPT ); Tue, 14 Feb 2006 15:12:54 -0500 Received: (qmail 6856 invoked from network); 14 Feb 2006 15:12:41 -0500 Received: from localhost (HELO raht.localdomain) (127.0.0.1) by localhost with SMTP; 14 Feb 2006 15:12:41 -0500 To: Linus Torvalds 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_Tue_Feb_14_12:10:23_2006-1 Content-Type: text/plain; charset=US-ASCII On Tue, 14 Feb 2006 10:34:35 -0800 (PST), Linus Torvalds wrote: > On Tue, 14 Feb 2006, Carl Worth wrote: > > > > I don't know if it's the original poster's question or not, but an > > operation I don't see in the above is "put the working files into the > > state of a given revision". > > What a strange thing to ask for. It's pretty common in other tools. For example, many tools have a way to examine the files from a previous state in a "no current branch" state. Any attempt to commit from that state would prompt the user to create a new branch name at that point. In fact, this is the natural operation for the basis of something like git-bisect. > It's actually as efficient as anything else, and there's much less room > for confusion. When you want to go back, you can just do a simple > > git checkout -f master OK, the efficiency arguments made elsewhere in the thread make it clear that these are the operations that need to happen. But I'd still like to be able to do this without having to invent a fake branch name, without the ability to accidentally commit on the fake branch, and without the possibility of accidentally leaving those commits dangling the next time I seek somewhere else. So I looked, and git-bisect does use this approach with a fake branch of "bisect" and by saving the original head ref in $GIT_DIR/head-name for the sake of the final "git bisect reset". Also, git-bisect does take advantage of the $GIT_DIR/head-name state to prevent nested calls to "git bisect start", ("won't bisect on seeked tree"). That gives a very natural name, "seek", for the operation I'd like. How about "git seek" for doing the operations above, and using some reserved branch name, (say "seek"). Then, git-bisect could easily be built on that, and git-commit could respect the "seek" name and refuse to commit to it, (could tell the user how to create the branch necessary to commit from the current point). There could also be a "git seek reset" to return to the HEAD saved by the first in a chain of "git seek" operations. That looks like I minor generalization of existing behavior in git-bisect, but it would provide an operation that I would find useful. -Carl --pgp-sign-Multipart_Tue_Feb_14_12:10:23_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBD8jk06JDdNq8qSWgRAsdVAJ9iBY39JpIq5PqFCZQ3yBIqpQaseQCfcnEp zpKhPG/9ONpDdyNqc/Avp4c= =mRX6 -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Feb_14_12:10:23_2006-1--