Re: [PATCH] kernel-docs.rst: update broken linuxjournal links

[Duy Nguyen]

On Sat, Dec 2, 2017 at 10:39 PM, Jonathan Corbet  wrote:
> On Thu, 30 Nov 2017 17:47:25 +0700
> Nguyễn Thái Ngọc Duy  wrote:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy 
>> ---
>>  Documentation/process/kernel-docs.rst | 14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> So I'm reluctant to take patches without a changelog.  One would help in
> this case...what is broken about these links?  They all work for me.  For
> as long as LJ links will work in general, I guess.

Hmm.. it was broken for me and I had to resort back to archive.org
before realizing that the content was probably still there under a
different url. Anyway the old urls do work for me now. Please ignore
the patch.

Re: [PATCH] kernel-docs.rst: update broken linuxjournal links

[Duy Nguyen]

On Sat, Dec 2, 2017 at 10:39 PM, Jonathan Corbet  wrote:
> On Thu, 30 Nov 2017 17:47:25 +0700
> Nguyễn Thái Ngọc Duy  wrote:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy 
>> ---
>>  Documentation/process/kernel-docs.rst | 14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> So I'm reluctant to take patches without a changelog.  One would help in
> this case...what is broken about these links?  They all work for me.  For
> as long as LJ links will work in general, I guess.

Hmm.. it was broken for me and I had to resort back to archive.org
before realizing that the content was probably still there under a
different url. Anyway the old urls do work for me now. Please ignore
the patch.

Re: [ANNOUNCE] Git v1.8.5-rc0

[Duy Nguyen]

On Thu, Oct 31, 2013 at 5:17 AM, Junio C Hamano  wrote:
>  * Magic pathspecs like ":(icase)makefile" that matches both
>Makefile and makefile can be used in more places.

":(glob)foo/**/bar" is another nice thing that could be announced.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Git v1.8.5-rc0

[Duy Nguyen]

On Thu, Oct 31, 2013 at 5:17 AM, Junio C Hamano gits...@pobox.com wrote:
  * Magic pathspecs like :(icase)makefile that matches both
Makefile and makefile can be used in more places.

:(glob)foo/**/bar is another nice thing that could be announced.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Duy Nguyen]

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
>> listing order.
>
> Hooks that take arbitrary amount of information from the body read
> their standard input. How are your multiple hooks supposed to
> interact?

If each only needs to read a few lines from stdin, they can do so in
order. If two hooks need to read till the end of stdin, they are
incompatible. If we support some sort of hook signature, we could warn
the user when they combine the two. If not, the second's failing
(because stdin is already closed) may show the incompatibility. "git
hook" should support dry-run mode to test out new combinations.

> Hooks that prevent you from doing something stupid signal allow/deny
> with their exit code. Do you fail a commit if any of your pre-commit
> hook fails, or is it OK to commit as long as one of them says so?
> If the former, do all the hooks described in the index still run, or
> does the first failure short-cut the remainder?

One failed hook fails the commit and stops the remaining from
executing. You can skip the hook if you want with --exclude-hooks.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Duy Nguyen]

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" hooks ("I want this behaviour in my repo(s)")
>  - "project" hooks ("In this project we follow these conventions")
>  - "system" hooks ("This host runs gitolite (or whatever) which needs
> these hooks...")
>  - "default" hooks (Some of the core Git code could have be
> implemented as hooks (e.g. "--signoff"), but is instead put into core
> Git)
>
> Maybe if we solved that problem, we could actually make use of hooks
> instead of adding "code" to our git configs (by which I mean config
> directives that are flexible enough to encode all kinds of semantics
> and behaviors that are probably better expressed in real code...).

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. There could be directories inside .git/hooks/something
to help categorize the scripts, so project hooks stay in "project"
subdirectory and so on.

With this we could provide "git hook" command to manipulate hooks and
test out the new combination of hooks. We could even select what
scripts not to run for a particular run, say you don't want the s-o-b
hook active when you commit this thing, you could run

  git commit --exclude-hooks=pre-commit-msg/s-o-b

You could exclude hooks by pattern as well

  git commit --exclude-hooks="pre-commit-msg/projects/*"

Or run an unsinstalled hook just one time

  git commit --include-hooks=/path/to/my/hook

Hooks like "Fixes" may need input from the user. The hook could bail
out if the required input is not given. But it maybe a good idea for
git to check and reject before running hooks, if the input is not
specified (e.g. from command line). I guess those extra info has to be
in .git/config and be added to .git/config by "git hook" command,
unless we have some convention to express those without running the hook.

For old Git versions that does not support this scheme, as directories
usually have u+x, the hook directory should be mistaken as an
executable and rejected when executed (permission denied in my test),
which gives user a good warning that this repo should not be used with
this git version.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Duy Nguyen]

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):

  - personal hooks (I want this behaviour in my repo(s))
  - project hooks (In this project we follow these conventions)
  - system hooks (This host runs gitolite (or whatever) which needs
 these hooks...)
  - default hooks (Some of the core Git code could have be
 implemented as hooks (e.g. --signoff), but is instead put into core
 Git)

 Maybe if we solved that problem, we could actually make use of hooks
 instead of adding code to our git configs (by which I mean config
 directives that are flexible enough to encode all kinds of semantics
 and behaviors that are probably better expressed in real code...).

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. There could be directories inside .git/hooks/something
to help categorize the scripts, so project hooks stay in project
subdirectory and so on.

With this we could provide git hook command to manipulate hooks and
test out the new combination of hooks. We could even select what
scripts not to run for a particular run, say you don't want the s-o-b
hook active when you commit this thing, you could run

  git commit --exclude-hooks=pre-commit-msg/s-o-b

You could exclude hooks by pattern as well

  git commit --exclude-hooks=pre-commit-msg/projects/*

Or run an unsinstalled hook just one time

  git commit --include-hooks=/path/to/my/hook

Hooks like Fixes may need input from the user. The hook could bail
out if the required input is not given. But it maybe a good idea for
git to check and reject before running hooks, if the input is not
specified (e.g. from command line). I guess those extra info has to be
in .git/config and be added to .git/config by git hook command,
unless we have some convention to express those without running the hook.

For old Git versions that does not support this scheme, as directories
usually have u+x, the hook directory should be mistaken as an
executable and rejected when executed (permission denied in my test),
which gives user a good warning that this repo should not be used with
this git version.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Duy Nguyen]

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 executed in the
 listing order.

 Hooks that take arbitrary amount of information from the body read
 their standard input. How are your multiple hooks supposed to
 interact?

If each only needs to read a few lines from stdin, they can do so in
order. If two hooks need to read till the end of stdin, they are
incompatible. If we support some sort of hook signature, we could warn
the user when they combine the two. If not, the second's failing
(because stdin is already closed) may show the incompatibility. git
hook should support dry-run mode to test out new combinations.

 Hooks that prevent you from doing something stupid signal allow/deny
 with their exit code. Do you fail a commit if any of your pre-commit
 hook fails, or is it OK to commit as long as one of them says so?
 If the former, do all the hooks described in the index still run, or
 does the first failure short-cut the remainder?

One failed hook fails the commit and stops the remaining from
executing. You can skip the hook if you want with --exclude-hooks.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Duy Nguyen]

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 hash in command line. I wonder if
we should approach it differently: the user writes "Fixes: " in
the commit message, then git detects these lines and expands them
using a user-configured format. For the kernel circle, the format
would be "%h ('%s')" (I'll need to think how to let the user say
"minimum 12 chars").

Other projects need to refer to old commits sometimes in commit
messages too and this could be extended further to expand inline
abbrev sha-1s, but to not break the text alignment badly, maybe
footnotes will be created to store subjects and stuff, rather than do
inline expansion. For example,

  commit 1232343 breaks something.

becomes

  comit 1232343 [1] breaks something

  [1] 123234332131 (do something wrong - at this date)
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Duy Nguyen]

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 copy/paste the hash in command line. I wonder if
we should approach it differently: the user writes Fixes: hash in
the commit message, then git detects these lines and expands them
using a user-configured format. For the kernel circle, the format
would be %h ('%s') (I'll need to think how to let the user say
minimum 12 chars).

Other projects need to refer to old commits sometimes in commit
messages too and this could be extended further to expand inline
abbrev sha-1s, but to not break the text alignment badly, maybe
footnotes will be created to store subjects and stuff, rather than do
inline expansion. For example,

  commit 1232343 breaks something.

becomes

  comit 1232343 [1] breaks something

  [1] 123234332131 (do something wrong - at this date)
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/