From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: several quick questions Date: Tue, 14 Feb 2006 13:53:10 -0800 Message-ID: <87d5hpvc8p.wl%cworth@cworth.org> References: <43F20532.5000609@iaglans.de> <87k6bxvmj6.wl%cworth@cworth.org> <87fymlvgzv.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_13:53:02_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 22:54:30 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 1F987m-0001lq-PW for gcvg-git@gmane.org; Tue, 14 Feb 2006 22:54:19 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422825AbWBNVyI (ORCPT ); Tue, 14 Feb 2006 16:54:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1422823AbWBNVyI (ORCPT ); Tue, 14 Feb 2006 16:54:08 -0500 Received: from theworths.org ([217.160.253.102]:11217 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1422828AbWBNVyG (ORCPT ); Tue, 14 Feb 2006 16:54:06 -0500 Received: (qmail 14965 invoked from network); 14 Feb 2006 16:54:05 -0500 Received: from localhost (HELO raht.localdomain) (127.0.0.1) by localhost with SMTP; 14 Feb 2006 16:54:05 -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_13:53:02_2006-1 Content-Type: text/plain; charset=US-ASCII On Tue, 14 Feb 2006 12:40:24 -0800 (PST), Linus Torvalds wrote: > > That's really my point. It all boils down to the same three operations: > "git branch", "git checkout" and "git reset". Yes. I understand that much. > I think that does exactly what you ask for, I just don't really see the > point. The downside of cg-seek is that you're really really limited to > what you can do with it. Well, I think it would be useful to generalize and export what git-bisect currently does even if there are no limitations added to it. If nothing else, it's a tiny bit of sugar to allow exploring the tree without having to invent a branch name first. So I'd be happy with "git seek" even if git-commit didn't refuse to commit on the seek branch, (but I still think that limitation makes sense---see below). > For example, if you hit a compile error, you can _literally_ fix that > compile error AND COMMIT that state, and when you then mark that commit > "good" or "bad" when you continue to bisect, bisection will actually do > the right thing. Something that would be impossible in a "seek" > environment, where you don't have a branch that you can do > development on. The only difference in the "seek" case would be that you would be required to create a branch before committing, right? And this would have the benefit of not leaving the commit object dangling after continuing the bisect, wouldn't it? You've pointed out that branches are free in terms of what git has to do. I'm saying that they're not free for the user who bears the cost of inventing a name. And in the case of any commit-while-seeking, it's at the time of the commit itself that the user has enough information to invent a useful name, not prior to seeking, (when the user is still trying to figure things out). -Carl --pgp-sign-Multipart_Tue_Feb_14_13:53:02_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBD8lFG6JDdNq8qSWgRArMoAKCJc1iR7M9AuY6s+iCpnMD2qDZM5gCgkeG3 HyCGGqVRIyzp2u2P+3trXJE= =1elL -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Feb_14_13:53:02_2006-1--