From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: Difficulties in advertising a new branch to git newbies Date: Tue, 06 Feb 2007 10:53:38 -0800 Message-ID: <87wt2vce31.wl%cworth@cworth.org> References: <87odognuhl.wl%cworth@cworth.org> <87y7nbdeaw.wl%cworth@cworth.org> <7vveifkczt.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Feb__6_10:53:32_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: git@vger.kernel.org To: Junio C Hamano X-From: git-owner@vger.kernel.org Tue Feb 06 19:54:17 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 1HEVSG-0007Tm-Ar for gcvg-git@gmane.org; Tue, 06 Feb 2007 19:54:12 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965302AbXBFSxl (ORCPT ); Tue, 6 Feb 2007 13:53:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965308AbXBFSxl (ORCPT ); Tue, 6 Feb 2007 13:53:41 -0500 Received: from cworth.org ([217.160.249.188]:45046 "EHLO theworths.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S965302AbXBFSxk (ORCPT ); Tue, 6 Feb 2007 13:53:40 -0500 Received: (qmail 5404 invoked from network); 6 Feb 2007 13:53:38 -0500 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 6 Feb 2007 13:53:38 -0500 In-Reply-To: <7vveifkczt.fsf@assigned-by-dhcp.cox.net> 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__6_10:53:32_2007-1 Content-Type: text/plain; charset=US-ASCII On Mon, 05 Feb 2007 22:37:42 -0800, Junio C Hamano wrote: > Carl Worth writes: > > > So, could we fix this so that a remote branch name will resolve > > without the "origin/" prefix if it is not ambiguous? > > I am fairly negative on this one, especially I do not think the > symptom deserves to be described with the word "fix". DWIM is > good, but it has bounds, and this particular one feels it is > slightly on the other side of the boundary. I can accept that argument. With "fix" I was referring to the backwards-compatibility problem, (that I don't have a way to give branch checkout instructions to users that will work for both 1.5 and pre-1.5 versions of git). As is, if I provide instructions that don't match the version the user has, then the user will see a rather confusing message: git checkout: updating paths is incompatible with switching branches/forcing Did you intend to checkout 'origin/8801' which can not be resolved as commit? [And perhaps the message above is evidence for too much DWIM in the interface already---that checkout will accept either a revision specifier or a path name and do fairly distinct operations depending on which it gets.] If my tail-matching-for-remotes idea won't fly, are there any other suggestions for a way to provide instructions for this step that would work across both 1.4 and 1.5 versions of git? > If you add another DWIM rule, then I suspect that you would have > harder time explaining why they get "hey, that is ambiguous" > error. Well, ideally git would explain the ambiguity with something like this: There are multiple "proposed-fix" remote-tracking branches. Please specify which you would like: origin/proposed-fix something-else/proposed-fix And I would think that this would not even be surprising since the user would not get into this situation by default, but would actually have to have added an additional something-else remote before being able to get this kind of ambiguity. But, like I said, I'm glad to accept that the tail-matching idea is a bad idea. Feel free to drop that on the floor. I'm more interested in the compatibility issue. -Carl --pgp-sign-Multipart_Tue_Feb__6_10:53:32_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFyM6y6JDdNq8qSWgRAq1dAKClA5BZ3TKX5BLb29NTZV6GfgZs7ACfdcDR MJiDQr8skvw1AeNVZ7zsImA= =2IDq -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Feb__6_10:53:32_2007-1--