linux-kernel - Re: [PATCH] commit: Add -f, --fixes <commit> option to add Fixes: line

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <526E1FD6.7040404@alum.mit.edu>
Date:	Mon, 28 Oct 2013 09:27:02 +0100
From:	Michael Haggerty <mhagger@...m.mit.edu>
To:	Josh Triplett <josh@...htriplett.org>,
	Junio C Hamano <gitster@...ox.com>
CC:	git@...r.kernel.org, Dan Carpenter <dan.carpenter@...cle.com>,
	Greg KH <greg@...ah.com>,
	ksummit-2013-discuss@...ts.linuxfoundation.org,
	ksummit-attendees@...ts.linuxfoundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] commit: Add -f, --fixes <commit> option to add Fixes:
 line

On 10/28/2013 08:16 AM, Josh Triplett wrote:
> 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')

It could be even more decoupled, for example like this:

[footer "Fixes"]
    type = pipe
    cmd = awk '{ print $1 }' | git log --stdin --no-walk --abbrev=12
--pretty=format:\"Fixes: %h ('%s')\"

Note that the command is written to be idempotent; that way git could
re-pipe the old value(s) of the footer though the command if necessary.
 And it can handle multiple lines, since some callback scripts might
want to see all of them at once.

Michael

-- 
Michael Haggerty
mhagger@...m.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/