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
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
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
':
--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
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) {
>>> ...
>>>
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
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
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",
>> +
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
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
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
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
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
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 +++
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
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
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
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
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
;
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
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 +++
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
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
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
;
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
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 +++
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
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
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
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
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
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
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
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?
(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
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
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
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
(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
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
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
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
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
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
@@ -
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
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
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
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
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
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:
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
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
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.
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
,
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
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
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
, 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
.
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
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
60 matches
Mail list logo