From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: [PATCH] bash-completion: fix getting strategy list Date: Wed, 20 Aug 2008 11:22:43 -0700 Message-ID: <7v3akzsg0c.fsf@gitster.siamese.dyndns.org> References: <20080819132803.GA26201@laptop> <48AADDBB.1080203@viscovery.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Johannes Sixt" , "Git Mailing List" To: "Nguyen Thai Ngoc Duy" X-From: git-owner@vger.kernel.org Wed Aug 20 20:24:11 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 1KVsLc-0004gb-0N for gcvg-git-2@gmane.org; Wed, 20 Aug 2008 20:23:56 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751708AbYHTSWv (ORCPT ); Wed, 20 Aug 2008 14:22:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751542AbYHTSWv (ORCPT ); Wed, 20 Aug 2008 14:22:51 -0400 Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:59752 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751285AbYHTSWv (ORCPT ); Wed, 20 Aug 2008 14:22:51 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 0ADD4604C6; Wed, 20 Aug 2008 14:22:49 -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-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 0608B604C5; Wed, 20 Aug 2008 14:22:44 -0400 (EDT) In-Reply-To: (Nguyen Thai Ngoc Duy's message of "Wed, 20 Aug 2008 23:58:14 +0700") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Pobox-Relay-ID: FE60DE58-6EE4-11DD-A0A2-3113EBD4C077-77302942!a-sasl-quonix.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: "Nguyen Thai Ngoc Duy" writes: > On second thought, I don't think the patch's worth it. The code in > git-completion.bash is a hack and I replace it with another the hack. > It won't work for custom merges and git-completion.bash will need to > be synced manually anyway, so maybe this patch will do better: This would be the right thing to do for the 'maint' track. In the longer term, especially if we are to actually make the "custom" thing official, I think teaching "git-merge" to report what are available is the only sensible approach, though.