On Wed, Oct 30, 2013 at 8:07 PM, Johan Herland jo...@herland.net wrote:
On Tue, Oct 29, 2013 at 7:23 AM, Christian Couder
christian.cou...@gmail.com wrote:
I don't agree. Git doesn't need to dictate anything to be able to do
these expansions.
Git only needs some hints to do these expansions
On Thu, Oct 31, 2013 at 1:12 AM, Johan Herland jo...@herland.net 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):
-
Duy Nguyen pclo...@gmail.com 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
On 10/27/2013 05:30 PM, Thomas Rast wrote:
Stefan Beller stefanbel...@googlemail.com 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)
On Fri, Nov 1, 2013 at 12:20 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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
On Thu, Oct 31, 2013 at 6:20 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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
On Sat, Oct 26, 2013 at 6:34 PM, Josh Triplett j...@joshtriplett.org 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
On Mon, Oct 28, 2013 at 11:10 PM, Thomas Rast t...@thomasrast.ch wrote:
Johan Herland jo...@herland.net 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
On Tue, Oct 29, 2013 at 3:08 AM, Jeff King p...@peff.net 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
Tony Luck tony.l...@gmail.com writes:
On Sat, Oct 26, 2013 at 6:34 PM, Josh Triplett j...@joshtriplett.org wrote:
+ format_commit_message(commit, Fixes: %h ('%s')\n, sb,
ctx);
What is the value of double wrapping the commit message inside '...'
and then ('...')?
Good point
On Tue, Oct 29, 2013 at 7:23 AM, Christian Couder
christian.cou...@gmail.com wrote:
On Mon, Oct 28, 2013 at 3:46 AM, Johan Herland jo...@herland.net wrote:
On Sun, Oct 27, 2013 at 8:04 PM, Christian Couder
christian.cou...@gmail.com wrote:
If git commit processes these arguments and puts the
On Mon, Oct 28, 2013 at 3:46 AM, Johan Herland jo...@herland.net wrote:
On Sun, Oct 27, 2013 at 8:04 PM, Christian Couder
christian.cou...@gmail.com wrote:
If git commit processes these arguments and puts the result in the
commit message file that is passed to the
prepare-commit-msg hook,
Jeff King p...@peff.net 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
Christian Couder christian.cou...@gmail.com writes:
On Mon, Oct 28, 2013 at 10:08 AM, Junio C Hamano gits...@pobox.com wrote:
Thinking aloud further, what I had in mind was along the lines of
the following.
* The most generic external interface would be spelled as
--trailer
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 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,
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 git in
the body of a message to majord...@vger.kernel.org
More majordomo
Junio C Hamano gits...@pobox.com 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
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't
On Mon, Oct 28, 2013 at 10:02 AM, Michael Haggerty mhag...@alum.mit.edu 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
Johan Herland jo...@herland.net 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,
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
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 annoying.
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 annoying.
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:
if one were to phrase
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 create new
On Mon, Oct 28, 2013 at 10:08 AM, Junio C Hamano gits...@pobox.com wrote:
Thinking aloud further, what I had in mind was along the lines of
the following.
* The most generic external interface would be spelled as
--trailer token[=param]
where token can be things like signoff,
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
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 (along
On Sun, Oct 27, 2013 at 12:14 AM, Josh Triplett j...@joshtriplett.org wrote:
+-f commit::
+--fixes=commit::
+ 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`
Josh Triplett j...@joshtriplett.org 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
On Sun, Oct 27, 2013 at 8:34 AM, Josh Triplett j...@joshtriplett.org 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
On Sun, Oct 27, 2013 at 03:33:19PM +0700, Duy Nguyen wrote:
On Sun, Oct 27, 2013 at 8:34 AM, Josh Triplett j...@joshtriplett.org 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
On Sun, Oct 27, 2013 at 09:09:32AM +0100, Thomas Rast wrote:
Josh Triplett j...@joshtriplett.org 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
On Sun, Oct 27, 2013 at 01:03:47AM -0700, Michel Lespinasse wrote:
On Sun, Oct 27, 2013 at 12:14 AM, Josh Triplett j...@joshtriplett.org wrote:
+-f commit::
+--fixes=commit::
+ Add Fixes line for the specified commit at the end of the commit
+ log message. This line includes an
On 10/27/2013 09:09 AM, Thomas Rast wrote:
Josh Triplett j...@joshtriplett.org 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
On Sun, Oct 27, 2013 at 10:20 AM, Josh Triplett j...@joshtriplett.org wrote:
On Sun, Oct 27, 2013 at 09:09:32AM +0100, Thomas Rast wrote:
Josh Triplett j...@joshtriplett.org writes:
On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
But I don't think that this feature should
Stefan Beller stefanbel...@googlemail.com 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
On 10/27/2013 05:30 PM, Thomas Rast wrote:
Stefan Beller stefanbel...@googlemail.com 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)
[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 jo...@herland.net wrote:
On Sun, Oct 27, 2013 at 10:20 AM, Josh Triplett j...@joshtriplett.org wrote:
...good suggestion:
~/src/linux$ git log --grep='stable@'
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
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
On Sun, Oct 27, 2013 at 8:04 PM, Christian Couder
christian.cou...@gmail.com wrote:
On Sun, Oct 27, 2013 at 2:30 PM, Johan Herland jo...@herland.net wrote:
On Sun, Oct 27, 2013 at 1:30 PM, Christian Couder
christian.cou...@gmail.com wrote:
Your suggestion is very good, and it is not
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 a
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 commit
45 matches
Mail list logo
