[PATCH] rebase docs: drop stray word in merge command description
Delete a misplaced word introduced by caafecfcf1 (rebase --rebase-merges: adjust man page for octopus support, 2018-03-09). Signed-off-by: Kyle Meyer --- Documentation/git-rebase.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index dff17b3178..2ee535fb23 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -979,7 +979,7 @@ when the merge operation did not even start), it is rescheduled immediately. At this time, the `merge` command will *always* use the `recursive` merge strategy for regular merges, and `octopus` for octopus merges, -strategy, with no way to choose a different one. To work around +with no way to choose a different one. To work around this, an `exec` command can be used to call `git merge` explicitly, using the fact that the labels are worktree-local refs (the ref `refs/rewritten/onto` would correspond to the label `onto`, for example). -- 2.19.2
Re: why doesn't "git reset" mention optional pathspec?
On Sat, Dec 8, 2018 at 6:37 PM Robert P. J. Day wrote: > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day > > wrote: > > > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > > > wrote: > > > > > > > > > > > > > > > from "man git-reset": > > > > > > > > > > SYNOPSIS > > > > > git reset [-q] [] [--] ... > > > > > git reset (--patch | -p) [] [--] [...] > > > > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > > > > [] > > > > > > > > > > oddly, the third form says nothing about possible "", even > > > > > though i'm pretty sure they're valid in that third case (at least > > > > > for "--mixed"). thoughts? is that just an oversight in the man > > > > > page? > > > > > > > > --mixed prints a deprecation warning. I don't think it's worth > > > > making the synopsis more complicated for that. All other modes > > > > reject pathspec. > > > > > > i just tested this, and i don't see a deprecation warning. > > > > Hmm.. maybe I misread the code. I just tried it > > > > $ ./git reset --mixed HEAD foo > > warning: --mixed with paths is deprecated; use 'git reset -- ' > > instead. > > weird ... i just tried this two ways, explicitly specifying > "--mixed" and also without (which is the default mode, right?), and i > got the deprecated message with the first but not the second. that > seems ... odd. Without --mixed, you're using the first form git reset [-q] [] [--] ... which accepts pathspec. If it's not clear, of course patches are welcome. -- Duy
Re: why doesn't "git reset" mention optional pathspec?
On Sat, 8 Dec 2018, Duy Nguyen wrote: > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > > wrote: > > > > > > > > > > > > from "man git-reset": > > > > > > > > SYNOPSIS > > > > git reset [-q] [] [--] ... > > > > git reset (--patch | -p) [] [--] [...] > > > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > > > [] > > > > > > > > oddly, the third form says nothing about possible "", even > > > > though i'm pretty sure they're valid in that third case (at least > > > > for "--mixed"). thoughts? is that just an oversight in the man > > > > page? > > > > > > --mixed prints a deprecation warning. I don't think it's worth > > > making the synopsis more complicated for that. All other modes > > > reject pathspec. > > > > i just tested this, and i don't see a deprecation warning. > > Hmm.. maybe I misread the code. I just tried it > > $ ./git reset --mixed HEAD foo > warning: --mixed with paths is deprecated; use 'git reset -- ' instead. my test: Changes to be committed: (use "git reset HEAD ..." to unstage) modified: README.asc modified: Rakefile $ git reset -- README.asc Unstaged changes after reset: M README.asc $ git reset --mixed -- Rakefile warning: --mixed with paths is deprecated; use 'git reset -- ' instead. Unstaged changes after reset: M README.asc M Rakefile $ that definitely seems inconsistent. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: why doesn't "git reset" mention optional pathspec?
On Sat, 8 Dec 2018, Duy Nguyen wrote: > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > > wrote: > > > > > > > > > > > > from "man git-reset": > > > > > > > > SYNOPSIS > > > > git reset [-q] [] [--] ... > > > > git reset (--patch | -p) [] [--] [...] > > > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > > > [] > > > > > > > > oddly, the third form says nothing about possible "", even > > > > though i'm pretty sure they're valid in that third case (at least > > > > for "--mixed"). thoughts? is that just an oversight in the man > > > > page? > > > > > > --mixed prints a deprecation warning. I don't think it's worth > > > making the synopsis more complicated for that. All other modes > > > reject pathspec. > > > > i just tested this, and i don't see a deprecation warning. > > Hmm.. maybe I misread the code. I just tried it > > $ ./git reset --mixed HEAD foo > warning: --mixed with paths is deprecated; use 'git reset -- ' instead. weird ... i just tried this two ways, explicitly specifying "--mixed" and also without (which is the default mode, right?), and i got the deprecated message with the first but not the second. that seems ... odd. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: why doesn't "git reset" mention optional pathspec?
On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > wrote: > > > > > > > > > from "man git-reset": > > > > > > SYNOPSIS > > > git reset [-q] [] [--] ... > > > git reset (--patch | -p) [] [--] [...] > > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > > [] > > > > > > oddly, the third form says nothing about possible "", even > > > though i'm pretty sure they're valid in that third case (at least > > > for "--mixed"). thoughts? is that just an oversight in the man > > > page? > > > > --mixed prints a deprecation warning. I don't think it's worth > > making the synopsis more complicated for that. All other modes > > reject pathspec. > > i just tested this, and i don't see a deprecation warning. Hmm.. maybe I misread the code. I just tried it $ ./git reset --mixed HEAD foo warning: --mixed with paths is deprecated; use 'git reset -- ' instead. -- Duy
Re: why doesn't "git reset" mention optional pathspec?
On Sat, 8 Dec 2018, Duy Nguyen wrote: > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote: > > > > > > from "man git-reset": > > > > SYNOPSIS > > git reset [-q] [] [--] ... > > git reset (--patch | -p) [] [--] [...] > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > [] > > > > oddly, the third form says nothing about possible "", even > > though i'm pretty sure they're valid in that third case (at least > > for "--mixed"). thoughts? is that just an oversight in the man > > page? > > --mixed prints a deprecation warning. I don't think it's worth > making the synopsis more complicated for that. All other modes > reject pathspec. i just tested this, and i don't see a deprecation warning. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: why doesn't "git reset" mention optional pathspec?
On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote: > > > from "man git-reset": > > SYNOPSIS > git reset [-q] [] [--] ... > git reset (--patch | -p) [] [--] [...] > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > [] > > oddly, the third form says nothing about possible "", even > though i'm pretty sure they're valid in that third case (at least for > "--mixed"). thoughts? is that just an oversight in the man page? --mixed prints a deprecation warning. I don't think it's worth making the synopsis more complicated for that. All other modes reject pathspec. -- Duy
[PATCH v4 4/7] pretty: allow showing specific trailers
Adds a new "key=X" option to "%(trailers)" which will cause it to only
print trailer lines which match any of the specified keys.
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 8 +
pretty.c | 47 ++---
t/t4205-log-pretty-formats.sh| 51
trailer.c| 10 ---
trailer.h| 2 ++
5 files changed, 110 insertions(+), 8 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index d33b072eb2..d6add831c0 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -225,6 +225,14 @@ endif::git-rev-list[]
linkgit:git-interpret-trailers[1]. The
`trailers` string may be followed by a colon
and zero or more comma-separated options:
+** 'key=': only show trailers with specified key. Matching is done
+ case-insensitively and trailing colon is optional. If option is
+ given multiple times trailer lines matching any of the keys are
+ shown. This option automatically enables the `only` option so that
+ non-trailer lines in the trailer block are hidden. If that is not
+ desired it can be disabled with `only=false`. E.g.,
+ `%(trailers:key=Reviewed-by)` shows trailer lines with key
+ `Reviewed-by`.
** 'only[=val]': select whether non-trailer lines from the trailer
block should be included. The `only` keyword may optionally be
followed by an equal sign and one of `true`, `on`, `yes` to omit or
diff --git a/pretty.c b/pretty.c
index 07e6c0..541a553ccc 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1056,13 +1056,20 @@ static size_t parse_padding_placeholder(struct strbuf
*sb,
return 0;
}
-static int match_placeholder_arg(const char *to_parse, const char *candidate,
-const char **end)
+static int match_placeholder_arg_value(const char *to_parse, const char
*candidate,
+ const char **end, const char
**valuestart, size_t *valuelen)
{
const char *p;
if (!(skip_prefix(to_parse, candidate, )))
return 0;
+ if (valuestart) {
+ if (*p != '=')
+ return 0;
+ *valuestart = p + 1;
+ *valuelen = strcspn(*valuestart, ",)");
+ p = *valuestart + *valuelen;
+ }
if (*p == ',') {
*end = p + 1;
return 1;
@@ -1074,6 +1081,12 @@ static int match_placeholder_arg(const char *to_parse,
const char *candidate,
return 0;
}
+static int match_placeholder_arg(const char *to_parse, const char *candidate,
+const char **end)
+{
+ return match_placeholder_arg_value(to_parse, candidate, end, NULL,
NULL);
+}
+
static int match_placeholder_bool_arg(const char *to_parse, const char
*candidate,
const char **end, int *val)
{
@@ -1095,7 +1108,19 @@ static int match_placeholder_bool_arg(const char
*to_parse, const char *candidat
*val = 1;
return 1;
}
+ return 0;
+}
+static int format_trailer_match_cb(const struct strbuf *key, void *ud)
+{
+ const struct string_list *list = ud;
+ const struct string_list_item *item;
+
+ for_each_string_list_item (item, list) {
+ if (key->len == (uintptr_t)item->util &&
+ !strncasecmp (item->string, key->buf, key->len))
+ return 1;
+ }
return 0;
}
@@ -1337,6 +1362,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (skip_prefix(placeholder, "(trailers", )) {
struct process_trailer_options opts =
PROCESS_TRAILER_OPTIONS_INIT;
+ struct string_list filter_list = STRING_LIST_INIT_NODUP;
size_t ret = 0;
opts.no_divider = 1;
@@ -1344,8 +1370,20 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (*arg == ':') {
arg++;
for (;;) {
- if (!match_placeholder_bool_arg(arg, "only",
, _trailers) &&
- !match_placeholder_bool_arg(arg, "unfold",
, ))
+ const char *argval;
+ size_t arglen;
+
+ if (match_placeholder_arg_value(arg, "key",
, , )) {
+ uintptr_t len = arglen;
+ if (len && argval[len - 1] == ':')
+ len--;
+ string_list_append(_list,
argval)->util = (char *)len;
+
+ opts.filter = format_trailer_match_cb;
+
[PATCH v4 3/7] pretty: single return path in %(trailers) handling
No functional change intended.
This change may not seem useful on its own, but upcoming commits will do
memory allocation in there, and a single return path makes deallocation
easier.
Signed-off-by: Anders Waldenborg
---
pretty.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/pretty.c b/pretty.c
index 26efdba73a..07e6c0 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1337,6 +1337,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (skip_prefix(placeholder, "(trailers", )) {
struct process_trailer_options opts =
PROCESS_TRAILER_OPTIONS_INIT;
+ size_t ret = 0;
opts.no_divider = 1;
@@ -1350,8 +1351,9 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
}
if (*arg == ')') {
format_trailers_from_commit(sb, msg + c->subject_off,
);
- return arg - placeholder + 1;
+ ret = arg - placeholder + 1;
}
+ return ret;
}
return 0; /* unknown placeholder */
--
2.17.1
[PATCH v4 0/7] %(trailers) improvements in pretty format
Updated since v3: * multiple 'key=' matches any * allow overriding implicit 'only' when using key * minor grammar and spelling fixes * documentation restructuring * Helper functions for parsing options Anders Waldenborg (7): doc: group pretty-format.txt placeholders descriptions pretty: allow %(trailers) options with explicit value pretty: single return path in %(trailers) handling pretty: allow showing specific trailers pretty: add support for "valueonly" option in %(trailers) strbuf: separate callback for strbuf_expand:ing literals pretty: add support for separator option in %(trailers) Documentation/pretty-formats.txt | 260 ++- pretty.c | 104 ++--- strbuf.c | 21 +++ strbuf.h | 8 + t/t4205-log-pretty-formats.sh| 111 + trailer.c| 25 ++- trailer.h| 4 + 7 files changed, 400 insertions(+), 133 deletions(-) -- 2.17.1
[PATCH v4 6/7] strbuf: separate callback for strbuf_expand:ing literals
Expanding '%n' and '%xNN' is generic functionality, so extract that from
the pretty.c formatter into a callback that can be reused.
No functional change intended
Signed-off-by: Anders Waldenborg
---
pretty.c | 16 +---
strbuf.c | 21 +
strbuf.h | 8
3 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/pretty.c b/pretty.c
index c508357606..50d0b5830d 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1133,9 +1133,13 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
const char *msg = c->message;
struct commit_list *p;
const char *arg;
- int ch;
+ size_t res;
/* these are independent of the commit */
+ res = strbuf_expand_literal_cb(sb, placeholder, NULL);
+ if (res)
+ return res;
+
switch (placeholder[0]) {
case 'C':
if (starts_with(placeholder + 1, "(auto)")) {
@@ -1154,16 +1158,6 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
*/
return ret;
}
- case 'n': /* newline */
- strbuf_addch(sb, '\n');
- return 1;
- case 'x':
- /* %x00 == NUL, %x0a == LF, etc. */
- ch = hex2chr(placeholder + 1);
- if (ch < 0)
- return 0;
- strbuf_addch(sb, ch);
- return 3;
case 'w':
if (placeholder[1] == '(') {
unsigned long width = 0, indent1 = 0, indent2 = 0;
diff --git a/strbuf.c b/strbuf.c
index f6a6cf78b9..78eecd29f7 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -380,6 +380,27 @@ void strbuf_expand(struct strbuf *sb, const char *format,
expand_fn_t fn,
}
}
+size_t strbuf_expand_literal_cb(struct strbuf *sb,
+ const char *placeholder,
+ void *context)
+{
+ int ch;
+
+ switch (placeholder[0]) {
+ case 'n': /* newline */
+ strbuf_addch(sb, '\n');
+ return 1;
+ case 'x':
+ /* %x00 == NUL, %x0a == LF, etc. */
+ ch = hex2chr(placeholder + 1);
+ if (ch < 0)
+ return 0;
+ strbuf_addch(sb, ch);
+ return 3;
+ }
+ return 0;
+}
+
size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder,
void *context)
{
diff --git a/strbuf.h b/strbuf.h
index fc40873b65..52e44c9ab8 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -320,6 +320,14 @@ void strbuf_expand(struct strbuf *sb,
expand_fn_t fn,
void *context);
+/**
+ * Used as callback for `strbuf_expand` to only expand literals
+ * (i.e. %n and %xNN). The context argument is ignored.
+ */
+size_t strbuf_expand_literal_cb(struct strbuf *sb,
+ const char *placeholder,
+ void *context);
+
/**
* Used as callback for `strbuf_expand()`, expects an array of
* struct strbuf_expand_dict_entry as context, i.e. pairs of
--
2.17.1
[PATCH v4 5/7] pretty: add support for "valueonly" option in %(trailers)
With the new "key=" option to %(trailers) it often makes little sense to
show the key, as it by definition already is knows which trailer is
printed there. This new "valueonly" option makes it omit the key when
printing trailers.
E.g.:
$ git show -s --pretty='%s%n%(trailers:key=Signed-off-by,valueonly)' 88182
will show:
> upload-pack: fix broken if/else chain in config callback
> Jeff King
> Junio C Hamano
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 2 ++
pretty.c | 3 ++-
t/t4205-log-pretty-formats.sh| 6 ++
trailer.c| 6 --
trailer.h| 1 +
5 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index d6add831c0..a920dd15b1 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -243,6 +243,8 @@ endif::git-rev-list[]
option was given. In same way as to for `only` it can be followed
by an equal sign and explicit value. E.g.,
`%(trailers:only,unfold=true)` unfolds and shows all trailer lines.
+** 'valueonly[=val]': skip over the key part of the trailer line and only
+ show the value part. Also this optionally allows explicit value.
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
diff --git a/pretty.c b/pretty.c
index 541a553ccc..c508357606 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1383,7 +1383,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
opts.filter_data = _list;
opts.only_trailers = 1;
} else if (!match_placeholder_bool_arg(arg,
"only", , _trailers) &&
- !match_placeholder_bool_arg(arg,
"unfold", , ))
+ !match_placeholder_bool_arg(arg,
"unfold", , ) &&
+ !match_placeholder_bool_arg(arg,
"valueonly", , _only))
break;
}
}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 54239290cf..22336c5485 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -667,6 +667,12 @@ test_expect_success 'pretty format
%(trailers:key=foo,only=no) also includes non
test_cmp expect actual
'
+test_expect_success '%(trailers:key=foo,valueonly) shows only value' '
+ git log --no-walk --pretty="format:%(trailers:key=Acked-by,valueonly)"
>actual &&
+ echo "A U Thor " >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'trailer parsing not fooled by --- line' '
git commit --allow-empty -F - <<-\EOF &&
this is the subject
diff --git a/trailer.c b/trailer.c
index d6da555cd7..d0d9e91631 100644
--- a/trailer.c
+++ b/trailer.c
@@ -1150,8 +1150,10 @@ static void format_trailer_info(struct strbuf *out,
if (!opts->filter || opts->filter(,
opts->filter_data)) {
if (opts->unfold)
unfold_value();
-
- strbuf_addf(out, "%s: %s\n", tok.buf, val.buf);
+ if (!opts->value_only)
+ strbuf_addf(out, "%s: ", tok.buf);
+ strbuf_addbuf(out, );
+ strbuf_addch(out, '\n');
}
strbuf_release();
strbuf_release();
diff --git a/trailer.h b/trailer.h
index 5255b676de..06d417fe93 100644
--- a/trailer.h
+++ b/trailer.h
@@ -72,6 +72,7 @@ struct process_trailer_options {
int only_input;
int unfold;
int no_divider;
+ int value_only;
int (*filter)(const struct strbuf *, void *);
void *filter_data;
};
--
2.17.1
[PATCH v4 1/7] doc: group pretty-format.txt placeholders descriptions
The placeholders can be grouped into three kinds:
* literals
* affecting formatting of later placeholders
* expanding to information in commit
Also change the list to a definition list (using '::')
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 235 ---
1 file changed, 125 insertions(+), 110 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 417b638cd8..86d804fe97 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -102,118 +102,133 @@ The title was >>t4119: test autocomputing -p for
traditional diff input.<<
+
The placeholders are:
-- '%H': commit hash
-- '%h': abbreviated commit hash
-- '%T': tree hash
-- '%t': abbreviated tree hash
-- '%P': parent hashes
-- '%p': abbreviated parent hashes
-- '%an': author name
-- '%aN': author name (respecting .mailmap, see linkgit:git-shortlog[1]
- or linkgit:git-blame[1])
-- '%ae': author email
-- '%aE': author email (respecting .mailmap, see
- linkgit:git-shortlog[1] or linkgit:git-blame[1])
-- '%ad': author date (format respects --date= option)
-- '%aD': author date, RFC2822 style
-- '%ar': author date, relative
-- '%at': author date, UNIX timestamp
-- '%ai': author date, ISO 8601-like format
-- '%aI': author date, strict ISO 8601 format
-- '%cn': committer name
-- '%cN': committer name (respecting .mailmap, see
- linkgit:git-shortlog[1] or linkgit:git-blame[1])
-- '%ce': committer email
-- '%cE': committer email (respecting .mailmap, see
- linkgit:git-shortlog[1] or linkgit:git-blame[1])
-- '%cd': committer date (format respects --date= option)
-- '%cD': committer date, RFC2822 style
-- '%cr': committer date, relative
-- '%ct': committer date, UNIX timestamp
-- '%ci': committer date, ISO 8601-like format
-- '%cI': committer date, strict ISO 8601 format
-- '%d': ref names, like the --decorate option of linkgit:git-log[1]
-- '%D': ref names without the " (", ")" wrapping.
-- '%e': encoding
-- '%s': subject
-- '%f': sanitized subject line, suitable for a filename
-- '%b': body
-- '%B': raw body (unwrapped subject and body)
+- Placeholders that expand to a single literal character:
+'%n':: newline
+'%%':: a raw '%'
+'%x00':: print a byte from a hex code
+
+- Placeholders that affect formatting of later placeholders:
+'%Cred':: switch color to red
+'%Cgreen':: switch color to green
+'%Cblue':: switch color to blue
+'%Creset':: reset color
+'%C(...)':: color specification, as described under Values in the
+"CONFIGURATION FILE" section of linkgit:git-config[1]. By
+default, colors are shown only when enabled for log output
+(by `color.diff`, `color.ui`, or `--color`, and respecting
+the `auto` settings of the former if we are going to a
+terminal). `%C(auto,...)` is accepted as a historical
+synonym for the default (e.g., `%C(auto,red)`). Specifying
+`%C(always,...) will show the colors even when color is
+not otherwise enabled (though consider just using
+`--color=always` to enable color for the whole output,
+including this format and anything else git might color).
+`auto` alone (i.e. `%C(auto)`) will turn on auto coloring
+on the next placeholders until the color is switched
+again.
+'%m':: left (`<`), right (`>`) or boundary (`-`) mark
+'%w([[,[,]]])':: switch line wrapping, like the -w option of
+linkgit:git-shortlog[1].
+'%<([,trunc|ltrunc|mtrunc])':: make the next placeholder take at
+ least N columns, padding spaces on
+ the right if necessary. Optionally
+ truncate at the beginning (ltrunc),
+ the middle (mtrunc) or the end
+ (trunc) if the output is longer than
+ N columns. Note that truncating
+ only works correctly with N >= 2.
+'%<|()':: make the next placeholder take at least until Nth
+ columns, padding spaces on the right if necessary
+'%>()', '%>|()':: similar to '%<()', '%<|()' respectively,
+but padding spaces on the left
+'%>>()', '%>>|()':: similar to '%>()', '%>|()'
+ respectively, except that if the next
+ placeholder takes more spaces than given and
+ there are spaces on its left, use those
+ spaces
+'%><()', '%><|()':: similar to '%<()', '%<|()'
+ respectively, but padding both sides
+ (i.e. the text is centered)
+
+- Placeholders that expand to information extracted from the commit:
+'%H':: commit hash
+'%h':: abbreviated commit hash
+'%T':: tree hash
+'%t':: abbreviated tree hash
+'%P':: parent
[PATCH v4 2/7] pretty: allow %(trailers) options with explicit value
In addition to old %(trailers:only) it is now allowed to write
%(trailers:only=yes)
By itself this only gives (the not quite so useful) possibility to have
users change their mind in the middle of a formatting
string (%(trailers:only=true,only=false)). However, it gives users the
opportunity to override defaults from future options.
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 14 ++
pretty.c | 32 +++-
t/t4205-log-pretty-formats.sh| 18 ++
3 files changed, 55 insertions(+), 9 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 86d804fe97..d33b072eb2 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -225,10 +225,16 @@ endif::git-rev-list[]
linkgit:git-interpret-trailers[1]. The
`trailers` string may be followed by a colon
and zero or more comma-separated options:
-** 'only': omit non-trailer lines from the trailer block.
-** 'unfold': make it behave as if interpret-trailer's `--unfold`
- option was given. E.g., `%(trailers:only,unfold)` unfolds and
- shows all trailer lines.
+** 'only[=val]': select whether non-trailer lines from the trailer
+ block should be included. The `only` keyword may optionally be
+ followed by an equal sign and one of `true`, `on`, `yes` to omit or
+ `false`, `off`, `no` to show the non-trailer lines. If option is
+ given without value it is enabled. If given multiple times the last
+ value is used.
+** 'unfold[=val]': make it behave as if interpret-trailer's `--unfold`
+ option was given. In same way as to for `only` it can be followed
+ by an equal sign and explicit value. E.g.,
+ `%(trailers:only,unfold=true)` unfolds and shows all trailer lines.
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
diff --git a/pretty.c b/pretty.c
index b83a3ecd23..26efdba73a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1074,6 +1074,31 @@ static int match_placeholder_arg(const char *to_parse,
const char *candidate,
return 0;
}
+static int match_placeholder_bool_arg(const char *to_parse, const char
*candidate,
+ const char **end, int *val)
+{
+ const char *p;
+ if (!skip_prefix(to_parse, candidate, ))
+ return 0;
+
+ if (match_placeholder_arg(p, "=no", end) ||
+ match_placeholder_arg(p, "=off", end) ||
+ match_placeholder_arg(p, "=false", end)) {
+ *val = 0;
+ return 1;
+ }
+
+ if (match_placeholder_arg(p, "", end) ||
+ match_placeholder_arg(p, "=yes", end) ||
+ match_placeholder_arg(p, "=on", end) ||
+ match_placeholder_arg(p, "=true", end)) {
+ *val = 1;
+ return 1;
+ }
+
+ return 0;
+}
+
static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
const char *placeholder,
void *context)
@@ -1318,11 +1343,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (*arg == ':') {
arg++;
for (;;) {
- if (match_placeholder_arg(arg, "only", ))
- opts.only_trailers = 1;
- else if (match_placeholder_arg(arg, "unfold",
))
- opts.unfold = 1;
- else
+ if (!match_placeholder_bool_arg(arg, "only",
, _trailers) &&
+ !match_placeholder_bool_arg(arg, "unfold",
, ))
break;
}
}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 978a8a66ff..63730a4ec0 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -578,6 +578,24 @@ test_expect_success '%(trailers:only) shows only "key:
value" trailers' '
test_cmp expect actual
'
+test_expect_success '%(trailers:only=yes) shows only "key: value" trailers' '
+ git log --no-walk --pretty=format:"%(trailers:only=yes)" >actual &&
+ grep -v patch.description expect &&
+ test_cmp expect actual
+'
+
+test_expect_success '%(trailers:only=no) shows all trailers' '
+ git log --no-walk --pretty=format:"%(trailers:only=no)" >actual &&
+ cat trailers >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success '%(trailers:only=no,only=true) shows only "key: value"
trailers' '
+ git log --no-walk --pretty=format:"%(trailers:only=yes)" >actual &&
+ grep -v patch.description expect &&
+ test_cmp expect actual
+'
+
[PATCH v4 7/7] pretty: add support for separator option in %(trailers)
By default trailer lines are terminated by linebreaks ('\n'). By
specifying the new 'separator' option they will instead be separated by
user provided string and have separator semantics rather than terminator
semantics. The separator string can contain the literal formatting codes
%n and %xNN allowing it to be things that are otherwise hard to type
such as %x00, or comma and end-parenthesis which would break parsing.
E.g:
$ git log --pretty='%(trailers:key=Reviewed-by,valueonly,separator=%x00)'
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 9
pretty.c | 10 +
t/t4205-log-pretty-formats.sh| 36
trailer.c| 15 +++--
trailer.h| 1 +
5 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index a920dd15b1..ce087dee80 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -239,6 +239,15 @@ endif::git-rev-list[]
`false`, `off`, `no` to show the non-trailer lines. If option is
given without value it is enabled. If given multiple times the last
value is used.
+** 'separator=': specify a separator inserted between trailer
+ lines. When this option is not given each trailer line is
+ terminated with a line feed character. The string SEP may contain
+ the literal formatting codes described above. To use comma as
+ separator one must use `%x2C` as it would otherwise be parsed as
+ next option. If separator option is given multiple times only the
+ last one is used. E.g., `%(trailers:key=Ticket,separator=%x2C )`
+ shows all trailer lines whose key is "Ticket" separated by a comma
+ and a space.
** 'unfold[=val]': make it behave as if interpret-trailer's `--unfold`
option was given. In same way as to for `only` it can be followed
by an equal sign and explicit value. E.g.,
diff --git a/pretty.c b/pretty.c
index 50d0b5830d..c7609493ee 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1357,6 +1357,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (skip_prefix(placeholder, "(trailers", )) {
struct process_trailer_options opts =
PROCESS_TRAILER_OPTIONS_INIT;
struct string_list filter_list = STRING_LIST_INIT_NODUP;
+ struct strbuf sepbuf = STRBUF_INIT;
size_t ret = 0;
opts.no_divider = 1;
@@ -1376,6 +1377,14 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
opts.filter = format_trailer_match_cb;
opts.filter_data = _list;
opts.only_trailers = 1;
+ } else if (match_placeholder_arg_value(arg,
"separator", , , )) {
+ char *fmt;
+
+ strbuf_reset();
+ fmt = xstrndup(argval, arglen);
+ strbuf_expand(, fmt,
strbuf_expand_literal_cb, NULL);
+ free(fmt);
+ opts.separator =
} else if (!match_placeholder_bool_arg(arg,
"only", , _trailers) &&
!match_placeholder_bool_arg(arg,
"unfold", , ) &&
!match_placeholder_bool_arg(arg,
"valueonly", , _only))
@@ -1387,6 +1396,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
ret = arg - placeholder + 1;
}
string_list_clear (_list, 0);
+ strbuf_release();
return ret;
}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 22336c5485..282369dac0 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -673,6 +673,42 @@ test_expect_success '%(trailers:key=foo,valueonly) shows
only value' '
test_cmp expect actual
'
+test_expect_success 'pretty format %(trailers:separator) changes separator' '
+ git log --no-walk --pretty=format:"X%(trailers:separator=%x00,unfold)X"
>actual &&
+ printf "XSigned-off-by: A U Thor \0Acked-by: A U
Thor \0[ v2 updated patch description ]\0Signed-off-by: A U
Thor X" >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'pretty format %(trailers) combining
separator/key/valueonly' '
+ git commit --allow-empty -F - <<-\EOF &&
+ Important fix
+
+ The fix is explained here
+
+ Closes: #1234
+ EOF
+
+ git commit --allow-empty -F - <<-\EOF &&
+ Another fix
+
+ The fix is explained here
+
+ Closes: #567
+ Closes: #890
+ EOF
+
+ git commit --allow-empty -F - <<-\EOF &&
+ Does
Re: [PATCH v3 1/1] git clone C:\cygwin\home\USER\repo' is working (again)
On Sat, Dec 8, 2018 at 9:11 AM wrote: > Changes since V2: latest patch still fixes original issue - thanks > - Settled on a better name: > The common code is in compat/win32/path-utils.c/h > [...] > - The "DOS" moniker is still used for 2 reasons: > Windows inherited the "drive letter" concept from DOS, > and everybody (tm) familar with the code and the path handling > in Git is used to that wording. > Even if there was a better name, it needed to be addressed > in a patch series different from this one. > Here I want to fix a reported regression. i still disagree with this - but i understand if naming argument is out of scope for thread > And, before any cleanup is done, I sould like to ask if anybody > can build the code with VS and confirm that it works, please ? sorry but i am decidedly *not* interested in doing this. i use cygwin specifically so that i can avoid VS. hopefully someone else will be able to test. cheers
Re: "git add -p" versus "git add -i", followed by "p"
On Sun, 2 Dec 2018, Duy Nguyen wrote: > On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote: > > > Patch update>> 2 > > > staged unstaged path > > > * 1:unchanged+1/-0 README.md > > > * 2:unchanged+1/-0 contrib/README > > > 3:unchanged+1/-0 t/README > > > Patch update>> > > > > > > Here I hit enter. Did you? > > > > perhaps i'm just not seeing it, but from "man git-add", it > > doesn't seem obvious that you would first select the files to work > > with, then hit a simple CR to get into actual patch mode. > > I think it's the same procedure as the "update" step, which > describes this in more detail. I agree that the "patch" section does > not make this obvious. when i get a chance, i'll try to reword it. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
why doesn't "git reset" mention optional pathspec?
from "man git-reset": SYNOPSIS git reset [-q] [] [--] ... git reset (--patch | -p) [] [--] [...] git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [] oddly, the third form says nothing about possible "", even though i'm pretty sure they're valid in that third case (at least for "--mixed"). thoughts? is that just an oversight in the man page? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[wishlist] submodule.update config
Relates (but orthogonal) to my other thread
[wishlist] git submodule update --reset-hard
ATM, it possible to specify per submodule update strategy via
configuration variable submodule.SUBMODULE.update where SUBMODULE is the name
of the corresponding submodule. But I see no way to specify default update
strategy for all submodules.
>From our conversation in that other thread I have discovered to myself about
existence of submodule.recurse configuration, and there seems to be a few
more (.fetchJobs, .active) where e.g. .active seems to complement per-submodule
submodule.*.active:
yoh@debian:~/proj/misc/git$ git grep '[^.]submodule\.[a-z]' --
Documentation/
Documentation/RelNotes/2.14.0.txt: * Many commands learned to pay
attention to submodule.recurse
Documentation/RelNotes/2.15.0.txt: * "git -c submodule.recurse=yes
pull" did not work as if the
Documentation/config.txt:include::config/submodule.txt[]
Documentation/config/submodule.txt: update'. If neither
submodule..active or submodule.active are
Documentation/config/submodule.txt: interact with submodules;
settings like `submodule.active`
Documentation/config/submodule.txt: submodule.active config option.
See linkgit:gitsubmodules[7] for
Documentation/config/submodule.txt: as computed via
`submodule.alternateLocation`. Possible values are
Documentation/git-clone.txt:of multiple entries. The resulting
clone has `submodule.active` set to
Documentation/git-clone.txt:Defaults to the `submodule.fetchJobs`
option.
Documentation/git-submodule.txt:If no path is specified and
submodule.active has been configured, submodules
Documentation/git-submodule.txt:Defaults to the
`submodule.fetchJobs` option.
Documentation/gitsubmodules.txt:`submodule.foo.path = path/to/bar`.
Documentation/gitsubmodules.txt:The section `submodule.foo.*` in the
`.gitmodules` file gives additional
Documentation/gitsubmodules.txt:hints to Git's porcelain layer. For
example, the `submodule.foo.url`
Documentation/gitsubmodules.txt: b. if the submodule's path matches
the pathspec in `submodule.active`
Documentation/gitsubmodules.txt:submodule's path is excluded in the
pathspec in `submodule.active`, the
Documentation/gitsubmodules.txt: git config --global submodule.recurse
true
Documentation/gitsubmodules.txt:your working tree. Alternatively you
can set 'submodule.recurse' to have
Documentation/technical/api-config.txt:if
(!git_configset_get_bool(gm_config, "submodule.frotz.ignore", )) {
Documentation/technical/http-protocol.txt: $GIT_URL:
http://example.com/git/repo.git/path/submodule.git
Documentation/technical/http-protocol.txt: URL request:
http://example.com/git/repo.git/path/submodule.git/info/refs
I wondered, if you think it would be sensible to also add of
submodule.update which would be considered before submodule.SUBMODULE.update
variable possibly defined per submodule. That would be more inline with desire
to use any of the --merge, --rebase (and hopefully soon --reset-hard)
strategies specified as an option for submodule update, where no per-submodule
handling is happening.
Thanks in advance for the consideration!
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
[PATCH v3 1/1] git clone C:\cygwin\home\USER\repo' is working (again)
From: Torsten Bögershausen
A regression for cygwin users was introduced with commit 05b458c,
"real_path: resolve symlinks by hand".
In the the commit message we read:
The current implementation of real_path uses chdir() in order to resolve
symlinks. Unfortunately this isn't thread-safe as chdir() affects a
process as a whole...
The old (and non-thread-save) OS calls chdir()/pwd() had been
replaced by a string operation.
The cygwin layer "knows" that "C:\cygwin" is an absolute path,
but the new string operation does not.
"git clone C:\cygwin\home\USER\repo" fails like this:
fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo'
The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
Extract the needed code into compat/win32/path-utils.[ch] and use it
for cygwin as well.
Reported-by: Steven Penny
Helped-by: Johannes Schindelin
Signed-off-by: Torsten Bögershausen
---
Changes since V2:
- Settled on a better name:
The common code is in compat/win32/path-utils.c/h
- Skip the 2 patches which "only" do a cleanup (for a moment)
put those cleanups onto the "todo stack".
- The "DOS" moniker is still used for 2 reasons:
Windows inherited the "drive letter" concept from DOS,
and everybody (tm) familar with the code and the path handling
in Git is used to that wording.
Even if there was a better name, it needed to be addressed
in a patch series different from this one.
Here I want to fix a reported regression.
And, before any cleanup is done, I sould like to ask if anybody
can build the code with VS and confirm that it works, please ?
Thanks for the reviews, testing and comment.
compat/cygwin.c | 19 ---
compat/cygwin.h | 2 --
compat/mingw.c| 29 +
compat/mingw.h| 20
compat/win32/path-utils.c | 28
compat/win32/path-utils.h | 20
config.mak.uname | 3 ++-
git-compat-util.h | 3 ++-
8 files changed, 53 insertions(+), 71 deletions(-)
delete mode 100644 compat/cygwin.c
delete mode 100644 compat/cygwin.h
create mode 100644 compat/win32/path-utils.c
create mode 100644 compat/win32/path-utils.h
diff --git a/compat/cygwin.c b/compat/cygwin.c
deleted file mode 100644
index b9862d606d..00
--- a/compat/cygwin.c
+++ /dev/null
@@ -1,19 +0,0 @@
-#include "../git-compat-util.h"
-#include "../cache.h"
-
-int cygwin_offset_1st_component(const char *path)
-{
- const char *pos = path;
- /* unc paths */
- if (is_dir_sep(pos[0]) && is_dir_sep(pos[1])) {
- /* skip server name */
- pos = strchr(pos + 2, '/');
- if (!pos)
- return 0; /* Error: malformed unc path */
-
- do {
- pos++;
- } while (*pos && pos[0] != '/');
- }
- return pos + is_dir_sep(*pos) - path;
-}
diff --git a/compat/cygwin.h b/compat/cygwin.h
deleted file mode 100644
index 8e52de4644..00
--- a/compat/cygwin.h
+++ /dev/null
@@ -1,2 +0,0 @@
-int cygwin_offset_1st_component(const char *path);
-#define offset_1st_component cygwin_offset_1st_component
diff --git a/compat/mingw.c b/compat/mingw.c
index 34b3880b29..27e397f268 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -350,7 +350,7 @@ static inline int needs_hiding(const char *path)
return 0;
/* We cannot use basename(), as it would remove trailing slashes */
- mingw_skip_dos_drive_prefix((char **));
+ win_path_utils_skip_dos_drive_prefix((char **));
if (!*path)
return 0;
@@ -2275,33 +2275,6 @@ pid_t waitpid(pid_t pid, int *status, int options)
return -1;
}
-int mingw_skip_dos_drive_prefix(char **path)
-{
- int ret = has_dos_drive_prefix(*path);
- *path += ret;
- return ret;
-}
-
-int mingw_offset_1st_component(const char *path)
-{
- char *pos = (char *)path;
-
- /* unc paths */
- if (!skip_dos_drive_prefix() &&
- is_dir_sep(pos[0]) && is_dir_sep(pos[1])) {
- /* skip server name */
- pos = strpbrk(pos + 2, "\\/");
- if (!pos)
- return 0; /* Error: malformed unc path */
-
- do {
- pos++;
- } while (*pos && !is_dir_sep(*pos));
- }
-
- return pos + is_dir_sep(*pos) - path;
-}
-
int xutftowcsn(wchar_t *wcs, const char *utfs, size_t wcslen, int utflen)
{
int upos = 0, wpos = 0;
diff --git a/compat/mingw.h b/compat/mingw.h
index 8c24ddaa3e..30d9fb3e36 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -443,32 +443,12 @@ HANDLE winansi_get_osfhandle(int fd);
* git specific compatibility
*/
-#define
Documentation: update "man git-add" to include "[]"
Current "man git-add" emphasizes single letter interactive shortcut commands with "[]". Signed-off-by: Robert P. J. Day --- diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 45652fe4a6..ad9bd7c7a6 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -239,8 +239,8 @@ and type return, like this: *** Commands *** - 1: status 2: update 3: revert 4: add untracked - 5: patch6: diff 7: quit 8: help + 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked + 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp What now> 1 -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [PATCH] mailmap: update brandon williams's email address
On Sat, Dec 08 2018, Junio C Hamano wrote: > Stefan Beller writes: > >> On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote: >>> >>> Brandon Williams wrote: >>> >>> > Signed-off-by: Brandon Williams >>> > --- >>> > .mailmap | 1 + >>> > 1 file changed, 1 insertion(+) >>> >>> I can confirm that this is indeed the same person. >> >> What would be more of interest is why we'd be interested in this patch >> as there is no commit/patch sent by Brandon with this email in gits history. > > Once I "git am" the message that began this thread, there will be a > commit under this new ident, so that would be somewhat a moot point. "Get to the top of 'git shortlog -sn' with this one easy trick" :) (The patch makes sense, good to see you back on-list Brandon)
Re: [PATCH] mailmap: update brandon williams's email address
On Sat, Dec 8, 2018 at 7:09 AM Junio C Hamano wrote: > If this were "Jonathan asked Brandon if we want to record an address > we can reach him in our .mailmap file and sent a patch to add one", Not sure about Jonathan, but I did. > then the story is different, and I tend to agree with you that such > a patch is more or less pointless. That's not the purpose of the > mailmap file. Not directly, but when multiple commands use mailmap to show the canonical mail addresses, then it kinda is. When I look back at an old commit message, I may look up the author name and address, which is mapped. > Not until git-send-email learns to use that file to rewrite > To/cc/etc to the "canonical" addresses, anyway ;-) git-send-email does not have to when I copy/paste the address from git-log anyway. > I am not sure if there are people whose "canonical" address to be > used as the author is not necessarily the best address they want to > get their e-mails at, though. If we can be reasonably sure that the > set of such people is empty, then people can take the above mention > about send-email as a hint about a low-hanging fruit ;-) > > Thanks. > > -- Duy
