[RFC/PATCH 0/2] Introduce safe-include config feature

is interpreted as a whitespace-separated list of, possibly negated, patterns. Later patterns override earlier ones. If the feature is deemed worthwhile and my approach is acceptable, I'll go ahead and try to write some documentation. For now, there is just a small test script. Rasmus Villemoes (2

[RFC/PATCH 1/2] config: Add safe-include directive

, so they will effectively just ignore them. Obviously, we must ignore safe-include.whitelist directives when we are processing a safe-included file. Signed-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk --- config.c | 91 +--- 1 file

[RFC/PATCH 2/2] config: Add test of safe-include feature

This adds a script for testing various aspects of the safe-include feature. Signed-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk --- t/t1309-config-safe-include.sh | 96 ++ 1 file changed, 96 insertions(+) create mode 100755 t/t1309-config-safe

Re: [RFC/PATCH 1/2] config: Add safe-include directive

Junio C Hamano gits...@pobox.com wrote: (by the way, we do not do dashes in names for configuration by convention) OK. Actually, I now think I'd prefer a subsection [include safe], but I don't have any strong preferences regarding the names. That syntax _could_ be just a relative path (e.g.

[RFC] git-send-email: Cache generated message-ids, use them when prompting

of the earlier email (which is cumbersome in some MUAs) and then copy-paste that. If this idea is accepted, I'm certain I'll get to use the feature immediately, since the patch is not quite ready for inclusion :-) Signed-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk --- git-send-email.perl | 101

[PATCH v2 0/2] git-send-email: Message-ID caching

in the process. [*] Suggestions for improving that heuristic are welcome. One thing that might be worthwhile is to give words ending in a colon higher weight. Rasmus Villemoes (2): git-send-email: add optional 'choices' parameter to the ask sub git-send-email: Cache generated message-ids, use them

[PATCH 1/2] git-send-email: add optional 'choices' parameter to the ask sub

, where the zeroth element is the choice and the first is used for the prompt. Signed-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk --- git-send-email.perl | 11 +++ 1 file changed, 11 insertions(+) diff --git a/git-send-email.perl b/git-send-email.perl index 2162478..ac3b02d 100755

[PATCH 2/2] git-send-email: Cache generated message-ids, use them when prompting

. Signed-off-by: Rasmus Villemoes r...@rasmusvillemoes.dk --- git-send-email.perl | 133 --- 1 file changed, 127 insertions(+), 6 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index ac3b02d..5094267 100755 --- a/git-send

Re: [PATCH 3/6] strbuf_getwholeline: use getc_unlocked

On Tue, Apr 07 2015, Jeff King p...@peff.net wrote: On Tue, Apr 07, 2015 at 03:48:33PM +0200, Rasmus Villemoes wrote: Implementation-wise, I think strbuf_getwholeline could be implemented mostly as a simple wrapper for getdelim. If I'm reading the current code and the posix spec for getdelim

Re: [PATCH 60/68] prefer memcpy to strcpy

On Thu, Sep 24 2015, Jeff King wrote: > This also eliminates calls to strcpy, which make auditing > the code base harder. Maybe may English parser is broken, but this doesn't immediately sound like what you meant to say. Also, in 29/68 you say "We drop calls to strcpy, which

Re: [PATCH] git-send-email: Add auto-cc to all body signatures

On Thu, Dec 08 2011, Joe Perches wrote: > On Thu, 2011-12-08 at 11:37 -0800, Junio C Hamano wrote: >> Joe Perches writes: >> > Many types of signatures are used by various projects. >> > The most common type is formatted: >> >"[some_signature_type]-by:

[PATCH 3/4] shallow.c: bit manipulation tweaks

compilers generate good code anyway. Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- shallow.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/shallow.c b/shallow.c index 8b1c35d..5aec5a5 100644 --- a/shallow.c +++ b/shallow.c @@ -464,7 +464,7 @@ stat

[PATCH 4/4] shallow.c: remove useless test

It seems to be odd to do x=y if x==y. Maybe there's a bug somewhere near this, but as is this is somewhat confusing. Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- shallow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shallow.c b/shallow.c index 5

[PATCH 1/4] shallow.c: make paint_alloc slightly more robust

ize. Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- shallow.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/shallow.c b/shallow.c index 4d0b005..e21534a 100644 --- a/shallow.c +++ b/shallow.c @@ -445,11 +445,13 @@ static uint32_t *paint_alloc(struct p

[PATCH 2/4] shallow.c: avoid theoretical pointer wrap-around

he LHS could wrap around 0, giving a false negative. This might as well be written using pointer subtraction avoiding these issues. Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- shallow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shallow.c b/shall

[PATCH 1/2] Documentation/config: add sendemail.tocmd to list preceding "See git-send-email(1)"

Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- Documentation/config.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 671fcbaa0..d88fc9f63 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -

[PATCH 2/2] completion: add git config sendemail.tocmd

Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index fdd984d34..10607cdf2 100644 --- a/contrib/completi

Documentation for update-index

The man page for update-index says -q Quiet. If --refresh finds that the index needs an update, the default behavior is to error out. This option makes git update-index continue anyway. --ignore-submodules Do not try to update submodules. This

[PATCH 1/3] grep: move grep_source_init outside critical section

(avoiding repeating the "GREP_SOURCE_OID, pathbuf.buf, path, oid" argument list); a subsequent cleanup patch will make that even more so. Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- builtin/grep.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletion

[PATCH 0/3] a few grep patches

I believe the first two should be ok, but I'm not sure what I myself think of the third one. Perhaps the saving is not worth the complexity, but it does annoy my optimization nerve to see all the unnecessary duplicated work being done. Rasmus Villemoes (3): grep: move grep_source_init outside

[PATCH 2/3] grep: simplify grep_oid and grep_file

In the NO_PTHREADS or !num_threads case, this doesn't change anything. In the threaded case, note that grep_source_init duplicates its third argument, so there is no need to keep [path]buf.buf alive across the call of add_work(). Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes

[PATCH 3/3] grep: avoid one strdup() per file

gs->identifier, and changing grep_source_clear accordingly to avoid a double free. Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- grep.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/grep.c b/grep.c index 3d7cd0e96..b1532b1b6 100644 --- a/grep.c

[RFC PATCH] cherry: teach git cherry to respect pathspec

y pathspec handling and (2) any argc other than 1..3 is treated as 0 - something which is probably also worth fixing. With this patch, the command above does give something reasonable, and t3500-cherry.sh also seems to pass. Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- bu

[PATCH v2 0/2] two small grep patches

he comment to explain why one then does the memset despite the first half of the comment. Rasmus Villemoes (2): grep: move grep_source_init outside critical section grep: simplify grep_oid and grep_file builtin/grep.c | 33 - 1 file changed, 20 insertions(+), 13

[PATCH v2 1/2] grep: move grep_source_init outside critical section

(avoiding repeating the long "GREP_SOURCE_OID, pathbuf.buf, path, oid" argument list); a subsequent cleanup patch will make that even more so. Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes.dk> --- builtin/grep.c | 27 ++- 1 file changed, 18 insertions

[PATCH v2 2/2] grep: simplify grep_oid and grep_file

In the NO_PTHREADS or !num_threads case, this doesn't change anything. In the threaded case, note that grep_source_init duplicates its third argument, so there is no need to keep [path]buf.buf alive across the call of add_work(). Signed-off-by: Rasmus Villemoes <r...@rasmusvillemoes

Re: feature request: allow commit.email config setting

On 2018-08-30 20:13, Eric Sunshine wrote: > On Thu, Aug 30, 2018 at 7:26 AM Rasmus Villemoes > wrote: >> I can set GIT_COMMITTER_EMAIL in the environment, but that is >> rather inconvenient, since that means I have to remember to do that in >> the shell I'm using for

feature request: allow commit.email config setting

As part of my dayjob, I did and still do some work on an upstream project. A while ago, I was granted commit access to that project. However, upstream asked that I would register with their system using a private email, or at least one that wouldn't change if I changed jobs, rather than my work

Re: [RFC PATCH] cherry: teach git cherry to respect pathspec

On 16 February 2018 at 02:15, Rasmus Villemoes <r...@rasmusvillemoes.dk> wrote: > This is a very naive attempt at teaching git cherry to restrict > attention to a given pathspec. Very much RFC, hence no documentation > update or test cases for now. > Ping, any comments on this?

[PATCH v2 3/3] send-email: also pick up cc addresses from -by trailers

own suppression category. It seems natural to make 'misc-by' implied by 'body'. Based-on-patch-by: Joe Perches Signed-off-by: Rasmus Villemoes --- Documentation/git-send-email.txt | 5 - git-send-email.perl | 19 --- 2 files changed, 16 insertions(+), 8 deletions

[PATCH v2 2/3] send-email: only consider lines containing @ or <> for automatic Cc'ing

garbage address, insist on at least a @ or a <> pair being present. This is also preparation for the next patch, where we are likely to encounter even more non-addresses in -by lines, such as Reported-by: Coverity Patch-generated-by: Coccinelle Signed-off-by: Rasmus Villemoes --- g

[PATCH v2 0/3] send-email: Also pick up cc addresses from -by trailers

': --suppress-cc * author, self, sob, cc, cccmd, body, bodycc, all. Rasmus Villemoes (3): Documentation/git-send-email.txt: style fixes send-email: only consider lines containing @ or <> for automatic Cc'ing send-email: also pick up cc addresses from -by trailers Documen

[PATCH v2 1/3] Documentation/git-send-email.txt: style fixes

For consistency, add full stops in a few places and outdent a line by one space. Signed-off-by: Rasmus Villemoes --- Documentation/git-send-email.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt

Re: [PATCH 3/3] send-email: also pick up cc addresses from -by trailers

On 2018-10-16 07:57, Junio C Hamano wrote: > Rasmus Villemoes writes: > >>> I wonder if it would make it easier to grok if we made the logic >>> inside out, i.e. >>> >>> if ($sc eq $sender) { >>> ... >>>

[PATCH v3 2/3] git.c: handle_alias: prepend alias info when first argument is -h

t hurt, and can help in figuring out what is happening in a case like $ git sc -h 'sc' is aliased to '!somecommand' somecommand: invalid option '-h' Suggested-by: Jeff King Signed-off-by: Rasmus Villemoes --- git.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/git.c b/git.c index a6

[PATCH v3 0/3] alias help tweaks

reports. Use better wording in patch 3. Rasmus Villemoes (3): help: redirect to aliased commands for "git cmd --help" git.c: handle_alias: prepend alias info when first argument is -h git-help.txt: document "git help cmd" vs "git cmd --help" for aliases Do

[PATCH v3 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases

This documents the existing behaviour of "git help cmd" when cmd is an alias, as well as providing a hint to use the "git cmd --help" form to be taken directly to the man page for the aliased command. Signed-off-by: Rasmus Villemoes --- Documentation/git-help.txt | 4 +++

[PATCH v3 1/3] help: redirect to aliased commands for "git cmd --help"

; case. [1] https://public-inbox.org/git/20180926102636.30691-1...@rasmusvillemoes.dk/ [2] https://public-inbox.org/git/20180926184914.gc30...@sigill.intra.peff.net/ Signed-off-by: Rasmus Villemoes --- builtin/help.c | 34 +++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git

Re: [PATCH v3 1/3] help: redirect to aliased commands for "git cmd --help"

On 2018-10-05 10:19, Junio C Hamano wrote: > Rasmus Villemoes writes: > >> >> I believe that printing the "is aliased to" message also in case (2) has >> value: Depending on pager setup, or if the user has help.format=web, the >> message is still p

[PATCH v4 0/3] alias help tweaks

reports. Use better wording in patch 3. v4: Reword commit log in patch 1. Rasmus Villemoes (3): help: redirect to aliased commands for "git cmd --help" git.c: handle_alias: prepend alias info when first argument is -h git-help.txt: document "git help cmd" vs "gi

[PATCH v4 1/3] help: redirect to aliased commands for "git cmd --help"

to stderr, it should never hurt. [1] https://public-inbox.org/git/20180926102636.30691-1...@rasmusvillemoes.dk/ [2] https://public-inbox.org/git/20180926184914.gc30...@sigill.intra.peff.net/ Signed-off-by: Rasmus Villemoes --- builtin/help.c | 34 +++--- 1 file changed, 31 in

[PATCH v4 2/3] git.c: handle_alias: prepend alias info when first argument is -h

t hurt, and can help in figuring out what is happening in a case like $ git sc -h 'sc' is aliased to '!somecommand' somecommand: invalid option '-h' Suggested-by: Jeff King Signed-off-by: Rasmus Villemoes --- git.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/git.c b/git.c index a6

[PATCH v4 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases

This documents the existing behaviour of "git help cmd" when cmd is an alias, as well as providing a hint to use the "git cmd --help" form to be taken directly to the man page for the aliased command. Signed-off-by: Rasmus Villemoes --- Documentation/git-help.txt | 4 +++

Re: [PATCH v2 1/3] help: redirect to aliased commands for "git cmd --help"

On 2018-10-03 04:13, Jeff King wrote: >> +/* >> + * If we were invoked as "git help cmd", or cmd is an >> + * alias for a shell command, we inform the user what >> + * cmd is an alias for and do nothing else. >> + */ >> +if

Re: [PATCH v2 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases

On 2018-10-03 04:18, Jeff King wrote: > On Mon, Oct 01, 2018 at 01:21:07PM +0200, Rasmus Villemoes wrote: > >> >> +If an alias is given, git prints a note explaining what it is an alias >> +for on standard output. To get the manual page for the aliased >> +co

Re: [PATCH] help: allow redirecting to help for aliased command

On 2018-09-26 20:12, Taylor Blau wrote: > > In the case where you are scripting (and want to know what 'git co' > means for programmatic usage), I think that there are two options. One, > which you note above, is the 'git -c help.followAlias=false ...' > approach, which I don't think is so bad

Re: [PATCH] help: allow redirecting to help for aliased command

On 2018-09-26 20:49, Jeff King wrote: > On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote: > >> >> If we expect users to use "git cp --help" a lot more often than "git >> help cp" (or the other way around), one way to give a nicer experience >> may be to unconditionally make "git cp

Re: [PATCH] help: allow redirecting to help for aliased command

On 2018-09-26 17:19, Duy Nguyen wrote: > On Wed, Sep 26, 2018 at 4:42 PM Taylor Blau wrote: >>> + >>> + /* >>> + * We use split_cmdline() to get the first word of the >>> + * alias, to ensure that we use the same rules as when >>> + * the alias

Re: [PATCH] help: allow redirecting to help for aliased command

On 2018-09-26 17:16, Junio C Hamano wrote: > Rasmus Villemoes writes: > >> +/* >> + * We use split_cmdline() to get the first word of the >> + * alias, to ensure that we use the same rules as when >> + * the alias i

Re: [PATCH 2/3] send-email: only consider lines containing @ or <> for automatic Cc'ing

On 2018-10-10 14:57, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Oct 10 2018, Rasmus Villemoes wrote: > >> +if ($c !~ /.+@.+|<.+>/) { >> +printf("(body) Ignoring %s from line '%s'\n", >> +

[PATCH 1/3] Documentation/git-send-email.txt: style fixes

For consistency, add full stops in a few places and outdent a line by one space. Signed-off-by: Rasmus Villemoes --- Documentation/git-send-email.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt

[PATCH 0/3] send-email: Also pick up cc addresses from -by trailers

in this line from 'git send-email -h': --suppress-cc * author, self, sob, cc, cccmd, body, bodycc, all. Rasmus Villemoes (3): Documentation/git-send-email.txt: style fixes send-email: only consider lines containing @ or <> for automatic Cc'ing send-email: also pick

[PATCH 3/3] send-email: also pick up cc addresses from -by trailers

own suppression category. It seems natural to make 'misc-by' implied by 'body'. Based-on-patch-by: Joe Perches Signed-off-by: Rasmus Villemoes --- Documentation/git-send-email.txt | 5 - git-send-email.perl | 14 -- 2 files changed, 12 insertions(+), 7 deletions

[PATCH 2/3] send-email: only consider lines containing @ or <> for automatic Cc'ing

garbage address, insist on at least a @ or a <> pair being present. This is also preparation for the next patch, where we are likely to encounter even more non-addresses in -by lines, such as Reported-by: Coverity Patch-generated-by: Coccinelle Signed-off-by: Rasmus Villemoes --- g

Re: [PATCH 2/3] send-email: only consider lines containing @ or <> for automatic Cc'ing

On 2018-10-11 08:06, Junio C Hamano wrote: > Rasmus Villemoes writes: > >> I considered that (and also had a version where I simply insisted on a @ >> being present), but that means the user no longer would get prompted >> about the cases where the address was just

Re: [PATCH 3/3] send-email: also pick up cc addresses from -by trailers

On 2018-10-11 08:18, Junio C Hamano wrote: > Rasmus Villemoes writes: > we now ... > >> +next if $suppress_cc{'sob'} and $what =~ >> /^Signed-off-by$/i; > > ... must make sure what we have is _exactly_ "signed-off-by" whe

[PATCH v2 3/3] git-help.txt: document "git help cmd" vs "git cmd --help" for aliases

This documents the existing behaviour of "git help cmd" when cmd is an alias, as well as providing a hint to use the "git cmd --help" form to be taken directly to the man page for the aliased command. Signed-off-by: Rasmus Villemoes --- Documentation/git-help.txt | 4 +++

[PATCH v2 2/3] git.c: handle_alias: prepend alias info when first argument is -h

t hurt, and can help in figuring out what is happening in a case like $ git sc -h 'sc' is aliased to '!somecommand' somecommand: invalid option '-h' Suggested-by: Jeff King Signed-off-by: Rasmus Villemoes --- git.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/git.c b/git.c index a6

[PATCH v2 1/3] help: redirect to aliased commands for "git cmd --help"

; case. [1] https://public-inbox.org/git/20180926102636.30691-1...@rasmusvillemoes.dk/ [2] https://public-inbox.org/git/20180926184914.gc30...@sigill.intra.peff.net/ Signed-off-by: Rasmus Villemoes --- builtin/help.c | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/bui

[PATCH] help: allow redirecting to help for aliased command

ent from the current behaviour of using stdout. I'm not sure what the most correct thing is, but I assume --help is mostly used interactively with stdout and stderr pointing at the same place. Signed-off-by: Rasmus Villemoes --- Documentation/config.txt | 10 ++ builtin/h