On Thu, Oct 31, 2013 at 6:20 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>> OK how about, if $GIT_DIR/hooks/something is a directory, then the
>> directory must contain a file named "index", listing all the hooks of
>> type "something". All the hooks in "index" will be executed in the
>> listi
On Fri, Nov 1, 2013 at 12:20 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> OK how about, if $GIT_DIR/hooks/something is a directory, then the
>> directory must contain a file named "index", listing all the hooks of
>> type "something". All the hooks in "index" will be executed in the
>> lis
Duy Nguyen writes:
> OK how about, if $GIT_DIR/hooks/something is a directory, then the
> directory must contain a file named "index", listing all the hooks of
> type "something". All the hooks in "index" will be executed in the
> listing order.
Hooks that take arbitrary amount of information fr
On Thu, Oct 31, 2013 at 1:12 AM, Johan Herland wrote:
> Yes, we do lack a good infrastructure for managing Git hooks from
> multiple sources. It makes people afraid to use them, because they
> might conflict with hooks from another source. There are (off the top
> of my head):
>
> - "personal" ho
On Tue, Oct 29, 2013 at 3:08 AM, Jeff King wrote:
> On Mon, Oct 28, 2013 at 12:29:32PM +0100, Johan Herland wrote:
>> > A hook-based solution could do this. But a built-in "all-purpose"
>> > handler like "footer.Fixes.arg=commit", which was intended to be
>> > reusable, wouldn't be able to do suc
On Sat, Oct 26, 2013 at 6:34 PM, Josh Triplett wrote:
> + format_commit_message(commit, "Fixes: %h ('%s')\n", sb, &ctx);
What is the value of double wrapping the commit message inside '...'
and then ('...')?
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-
Jeff King writes:
> We could probably make this friendlier by reading from ~/.githooks
> and defining some semantics for multiple hooks.
I'd be all for it, except I'd call this ~/.config/git/hooks/* (or
$XDG_CONFIG_HOME if set).
> E.g., fall back to ~/.githooks if the repo hook is not
> execut
On Mon, Oct 28, 2013 at 11:10:13PM +0100, Thomas Rast wrote:
> * In your list
>
> > Fixes:
> > Reported-by:
> > Suggested-by:
> > Improved-by:
> > Acked-by:
> > Reviewed-by:
> > Tested-by:
> > Signed-off-by:
>
> and I might add
>
> Cherry-picked-from:
> Reverts:
>
>
On Mon, Oct 28, 2013 at 12:29:32PM +0100, Johan Herland wrote:
> > A hook-based solution could do this. But a built-in "all-purpose"
> > handler like "footer.Fixes.arg=commit", which was intended to be
> > reusable, wouldn't be able to do such footer-specific extra work without
> > having to crea
[ I've removed Junio and the git mailing list form the -cc ]
On Mon, Oct 28, 2013 at 11:41:17PM +, Russell King - ARM Linux wrote:
>
> I agree too. This whole thread seems to be about noise, and I too
> thought there was something about not cross-posting between this list
> and any other lis
On Tue, Oct 29, 2013 at 10:09:53AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote:
> > Btw, can we please take away this discussion from ksummit-attendees? It's
> > got
> > absolutely nothing to do with kernel summit and is getting fairly annoyin
On Tue, Oct 29, 2013 at 10:09:53AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote:
> > Btw, can we please take away this discussion from ksummit-attendees? It's
> > got
> > absolutely nothing to do with kernel summit and is getting fairly annoyin
On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote:
> Btw, can we please take away this discussion from ksummit-attendees? It's got
> absolutely nothing to do with kernel summit and is getting fairly annoying.
Ack. Additionally, iirc, we had decided that
- We don't cross post multiple l
Johan Herland writes:
> But I still don't see exactly what this option should do (inside "git
> commit") that would end up being useful across most/all projects, and
> not just something that could more easily be implemented in the
> *commit-msg hooks for relevant projects.
[Ok, admittedly I don
On Mon, Oct 28, 2013 at 10:02 AM, Michael Haggerty wrote:
> On 10/27/2013 08:14 AM, Josh Triplett wrote:
>> On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
>>> On 10/27/2013 02:34 AM, Josh Triplett wrote:
>>> I wonder if the two features could
>>> be combined in some way?
>>>
>>>
On 10/27/2013 08:14 AM, Josh Triplett wrote:
> On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
>> On 10/27/2013 02:34 AM, Josh Triplett wrote:
>> [...]
>> First of all, let me show my ignorance. How formalized is the use of
>> metadata lines at the end of a commit message? I don
Junio C Hamano writes:
> 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
>
Btw, can we please take away this discussion from ksummit-attendees? It's got
absolutely nothing to do with kernel summit and is getting fairly annoying.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
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 on
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
On Sun, Oct 27, 2013 at 8:04 PM, Christian Couder
wrote:
> On Sun, Oct 27, 2013 at 2:30 PM, Johan Herland wrote:
>> On Sun, Oct 27, 2013 at 1:30 PM, Christian Couder
>> wrote:
>>>
>>> Your suggestion is very good, and it is not incompatible with command
>>> line options.
>>> So both could be im
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 interfac
On 10/26/13 18:34, Josh Triplett wrote:
Linux Kernel ... "Fixes:" line ... containing an abbreviated commit hash
This helps people (or automated tools) determine how far to backport
I beg pardon if I'm rehearsing an old debate, but it seems to me it
would be better and worthwhile to bring
[Sorry I already sent the reply below to Johan only instead of everyone.]
Hi Johan,
On Sun, Oct 27, 2013 at 11:59 AM, Johan Herland wrote:
> On Sun, Oct 27, 2013 at 10:20 AM, Josh Triplett wrote:
>>
>> ...good suggestion:
>>
>> ~/src/linux$ git log --grep='stable@' --oneline --since='1 year ago
On 10/27/2013 05:30 PM, Thomas Rast wrote:
> Stefan Beller writes:
>
>> I assembled an overview table, which plots the long options of
>> git commands by the short letters.
> [...]
>> (In case thunderbird messes it up, here it is again
>> http://pastebin.com/raw.php?i=JBci2Krx)
>>
>> As you can
Stefan Beller writes:
> I assembled an overview table, which plots the long options of
> git commands by the short letters.
[...]
> (In case thunderbird messes it up, here it is again
> http://pastebin.com/raw.php?i=JBci2Krx)
>
> As you can see, f is always --force except for git-config, where
On Sun, Oct 27, 2013 at 10:20 AM, Josh Triplett wrote:
> On Sun, Oct 27, 2013 at 09:09:32AM +0100, Thomas Rast wrote:
>> Josh Triplett writes:
>> > On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
>> >> But I don't think that this feature should be given the "-f" short
>> >> opti
On 10/27/2013 09:09 AM, Thomas Rast wrote:
> Josh Triplett writes:
>
>> On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
>>> But I don't think that this feature should be given the "-f" short
>>> option, as (a) -f often means "force"; (b) it will increase the
>>> confusion with -
On Sun, Oct 27, 2013 at 01:03:47AM -0700, Michel Lespinasse wrote:
> On Sun, Oct 27, 2013 at 12:14 AM, Josh Triplett wrote:
> >> > +-f ::
> >> > +--fixes=::
> >> > + Add Fixes line for the specified commit at the end of the commit
> >> > + log message. This line includes an abbreviated commit
On Sun, Oct 27, 2013 at 09:09:32AM +0100, Thomas Rast wrote:
> Josh Triplett writes:
>
> > On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
> >> But I don't think that this feature should be given the "-f" short
> >> option, as (a) -f often means "force"; (b) it will increase the
On Sun, Oct 27, 2013 at 03:33:19PM +0700, Duy Nguyen wrote:
> On Sun, Oct 27, 2013 at 8:34 AM, Josh Triplett wrote:
> > Add a command line option for git commit to automatically construct the
> > "Fixes:" line for a commit. This avoids the need to manually construct
> > that line by copy-pasting
On Sun, Oct 27, 2013 at 8:34 AM, Josh Triplett wrote:
> Add a command line option for git commit to automatically construct the
> "Fixes:" line for a commit. This avoids the need to manually construct
> that line by copy-pasting the commit hash and subject.
But you still have to copy/paste the h
Josh Triplett writes:
> On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
>> But I don't think that this feature should be given the "-f" short
>> option, as (a) -f often means "force"; (b) it will increase the
>> confusion with --fixup; (c) it just doesn't strike me as being like
On Sun, Oct 27, 2013 at 12:14 AM, Josh Triplett wrote:
>> > +-f ::
>> > +--fixes=::
>> > + Add Fixes line for the specified commit at the end of the commit
>> > + log message. This line includes an abbreviated commit hash for
>> > + the specified commit; the `core.abbrev` option determines
On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
> On 10/27/2013 02:34 AM, Josh Triplett wrote:
> > Linux Kernel Summit 2013 decided on a commit message convention to
> > identify commits containing bugs fixed by a commit: a "Fixes:" line,
> > included in the standard commit footer
One of the uses of the Fixes commit line is so that when we fix a
security bug that has been in mainline for a while, it can be tricky
to determine whether it should be backported in to the various stable
branches. For example, let's suppose the security bug (or any bug,
but one of the contexts wh
On 10/27/2013 02:34 AM, Josh Triplett wrote:
> Linux Kernel Summit 2013 decided on a commit message convention to
> identify commits containing bugs fixed by a commit: a "Fixes:" line,
> included in the standard commit footer (along with "Signed-off-by:" if
> present), containing an abbreviated com
Linux Kernel Summit 2013 decided on a commit message convention to
identify commits containing bugs fixed by a commit: a "Fixes:" line,
included in the standard commit footer (along with "Signed-off-by:" if
present), containing an abbreviated commit hash (at least 12 characters
to keep it valid for
38 matches
Mail list logo
