From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: [PATCH v4] for-each-ref: `:short` format for `refname` Date: Tue, 09 Sep 2008 01:05:32 -0700 Message-ID: <7vod2xagmr.fsf@gitster.siamese.dyndns.org> References: <7vtzcxaxgr.fsf@gitster.siamese.dyndns.org> <1220649383-17916-1-git-send-email-bert.wesarg@googlemail.com> <7vfxoadz5c.fsf@gitster.siamese.dyndns.org> <36ca99e90809082352q3c87447eme73379673fe652f4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Junio C Hamano" , git@vger.kernel.org, szeder@ira.uka.de, "Shawn O. Pearce" To: "Bert Wesarg" X-From: git-owner@vger.kernel.org Tue Sep 09 10:07:07 2008 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1KcyFP-0007Rz-EM for gcvg-git-2@gmane.org; Tue, 09 Sep 2008 10:06:51 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754566AbYIIIFn (ORCPT ); Tue, 9 Sep 2008 04:05:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754637AbYIIIFm (ORCPT ); Tue, 9 Sep 2008 04:05:42 -0400 Received: from a-sasl-fastnet.sasl.smtp.pobox.com ([207.106.133.19]:50920 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754313AbYIIIFl (ORCPT ); Tue, 9 Sep 2008 04:05:41 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id C2E495F617; Tue, 9 Sep 2008 04:05:40 -0400 (EDT) Received: from pobox.com (ip68-225-240-211.oc.oc.cox.net [68.225.240.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id B56E65F616; Tue, 9 Sep 2008 04:05:34 -0400 (EDT) In-Reply-To: <36ca99e90809082352q3c87447eme73379673fe652f4@mail.gmail.com> (Bert Wesarg's message of "Tue, 9 Sep 2008 08:52:00 +0200") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Pobox-Relay-ID: 18158496-7E46-11DD-87BA-D0CFFE4BC1C1-77302942!a-sasl-fastnet.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: "Bert Wesarg" writes: > Any opinions, whether we want the 'strict' mode? i.e.: > > for refs/heads/xyzzy and refs/tags/xyzzy: > > loose mode (current implementation): > > refs/heads/xyzzy => heads/xyzzy > refs/tags/xyzzy => xyzzy > > there would be a ambiguous warning (if enabled) if you use xyzzy as a > tag, but it resolves correctly to the tag. > > strict mode: > > refs/heads/xyzzy => heads/xyzzy > refs/tags/xyzzy => tags/xyzzy > > will always produce a non-ambiguous short forms. I have no strong opinions either way, but if we want to pick only one, I suspect that the loose mode would be more appropriate for bash completion purposes exactly because: (1) the shorter form would match the users' expectations, and; (2) if it triggers ambiguity warning to use that result that matches users' expectations, it is a *good thing* --- it reminds the user that s/he is playing with fire _if_ the user is of careful type who enables the ambiguity warning. Thinking about it from a different angle, it would make more sense to use loose mode if the user does not have ambiguity warning configured, and use strict mode if the warning is enabled. Then people who will get warnings from ambiguity will not get an ambiguous completion, and people who won't will get shorter but still unambiguous completion. Which means, despite what I said earlier, now I have a mild preference to tie the choice to core.wawrnambigousrefs configuration.