Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755602Ab3J1HQO (ORCPT ); Mon, 28 Oct 2013 03:16:14 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:43764 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752802Ab3J1HQN (ORCPT ); Mon, 28 Oct 2013 03:16:13 -0400 X-Originating-IP: 77.221.165.98 Date: Mon, 28 Oct 2013 07:16:06 +0000 From: Josh Triplett To: Junio C Hamano Cc: git@vger.kernel.org, Dan Carpenter , Greg KH , ksummit-2013-discuss@lists.linuxfoundation.org, ksummit-attendees@lists.linuxfoundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] commit: Add -f, --fixes option to add Fixes: line Message-ID: <20131028071606.GA16878@leaf> References: <20131024122255.GI9378@mwanda> <20131024122512.GB9534@mwanda> <20131026181709.GB10488@kroah.com> <20131027013402.GA7146@leaf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2257 Lines: 48 On Sun, Oct 27, 2013 at 06:52:18PM -0700, Junio C Hamano wrote: > There are unbound number of kinds of trailers people would want to > add, depending on their projects' needs. We should not have to add > a specific support for a tailer like this one, before thinking > through to see if we can add generic support for adding arbitrary > trailers to avoid code and interface bloat. > > Think of the existing --signoff as a historical mistake. Such a > generic "adding arbitrary trailers" support, when done properly, > should be able to express what "--signoff" does, and we should be > able to redo "--signoff" as a special case of that generic "adding > arbitrary trailers" support, and at that point, "Fixes:" trailer the > kernel project wants to use should fall out as a natural consequence. Well, the add_signoff_extra function I added makes it easy to add any kind of trailing data you want to a commit; the question just becomes what the UI looks like to drive that. Would you be OK with a solution that pushes the specific supported footer lines into git's configuration, and then supplies default configuration for common cases such as Fixes? The option could become -f/--footer, and the configuration would specify how to parse various arguments of -f and turn them into something. For example: [footer "Fixes"] abbrev = f arg = commit format = %h ('%s') git commit -f Cc:stable@vger.kernel.org -f f:bad-commit ... The Cc line there would go unparsed since there's no specific support for it, while the 'f:bad-commit' would get expanded by the configuration above to parse bad-commit as a committish and format it using the specified pretty format. Look reasonable? I could start out by adding support for footer lines that take commits as arguments and format them using arbitrary pretty strings, and leave room for future expansion to support footers that reference idents (given some way to expand idents from some shorter form, otherwise there's no point). - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/