2007-04-27 07:41:15 +00:00
|
|
|
#include "cache.h"
|
2008-07-21 18:03:49 +00:00
|
|
|
#include "string-list.h"
|
2007-04-30 22:31:52 +00:00
|
|
|
#include "mailmap.h"
|
2007-04-27 07:41:15 +00:00
|
|
|
|
2009-02-08 14:34:29 +00:00
|
|
|
#define DEBUG_MAILMAP 0
|
|
|
|
#if DEBUG_MAILMAP
|
|
|
|
#define debug_mm(...) fprintf(stderr, __VA_ARGS__)
|
2013-07-15 06:54:12 +00:00
|
|
|
#define debug_str(X) ((X) ? (X) : "(none)")
|
2009-02-08 14:34:29 +00:00
|
|
|
#else
|
|
|
|
static inline void debug_mm(const char *format, ...) {}
|
2013-07-15 06:54:12 +00:00
|
|
|
static inline const char *debug_str(const char *s) { return s; }
|
2009-02-08 14:34:29 +00:00
|
|
|
#endif
|
|
|
|
|
2009-02-08 14:34:27 +00:00
|
|
|
const char *git_mailmap_file;
|
2012-12-12 11:04:04 +00:00
|
|
|
const char *git_mailmap_blob;
|
2009-02-08 14:34:29 +00:00
|
|
|
|
|
|
|
struct mailmap_info {
|
|
|
|
char *name;
|
|
|
|
char *email;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct mailmap_entry {
|
|
|
|
/* name and email for the simple mail-only case */
|
|
|
|
char *name;
|
|
|
|
char *email;
|
|
|
|
|
|
|
|
/* name and email for the complex mail and name matching case */
|
|
|
|
struct string_list namemap;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void free_mailmap_info(void *p, const char *s)
|
|
|
|
{
|
|
|
|
struct mailmap_info *mi = (struct mailmap_info *)p;
|
2013-07-15 06:54:13 +00:00
|
|
|
debug_mm("mailmap: -- complex: '%s' -> '%s' <%s>\n",
|
|
|
|
s, debug_str(mi->name), debug_str(mi->email));
|
2009-02-08 14:34:29 +00:00
|
|
|
free(mi->name);
|
|
|
|
free(mi->email);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_mailmap_entry(void *p, const char *s)
|
|
|
|
{
|
|
|
|
struct mailmap_entry *me = (struct mailmap_entry *)p;
|
2013-07-15 06:54:13 +00:00
|
|
|
debug_mm("mailmap: removing entries for <%s>, with %d sub-entries\n",
|
|
|
|
s, me->namemap.nr);
|
|
|
|
debug_mm("mailmap: - simple: '%s' <%s>\n",
|
|
|
|
debug_str(me->name), debug_str(me->email));
|
2013-07-15 06:54:12 +00:00
|
|
|
|
2009-02-08 14:34:29 +00:00
|
|
|
free(me->name);
|
|
|
|
free(me->email);
|
|
|
|
|
|
|
|
me->namemap.strdup_strings = 1;
|
|
|
|
string_list_clear_func(&me->namemap, free_mailmap_info);
|
|
|
|
}
|
|
|
|
|
2013-09-12 15:37:08 +00:00
|
|
|
/*
|
|
|
|
* On some systems (e.g. MinGW 4.0), string.h has _only_ inline
|
|
|
|
* definition of strcasecmp and no non-inline implementation is
|
|
|
|
* supplied anywhere, which is, eh, "unusual"; we cannot take an
|
|
|
|
* address of such a function to store it in namemap.cmp. This is
|
|
|
|
* here as a workaround---do not assign strcasecmp directly to
|
|
|
|
* namemap.cmp until we know no systems that matter have such an
|
|
|
|
* "unusual" string.h.
|
|
|
|
*/
|
|
|
|
static int namemap_cmp(const char *a, const char *b)
|
|
|
|
{
|
|
|
|
return strcasecmp(a, b);
|
|
|
|
}
|
|
|
|
|
2009-02-08 14:34:29 +00:00
|
|
|
static void add_mapping(struct string_list *map,
|
2013-07-15 06:54:13 +00:00
|
|
|
char *new_name, char *new_email,
|
|
|
|
char *old_name, char *old_email)
|
2009-02-08 14:34:29 +00:00
|
|
|
{
|
|
|
|
struct mailmap_entry *me;
|
2014-11-25 03:44:14 +00:00
|
|
|
struct string_list_item *item;
|
2009-03-31 00:18:36 +00:00
|
|
|
|
2009-02-08 14:34:29 +00:00
|
|
|
if (old_email == NULL) {
|
|
|
|
old_email = new_email;
|
|
|
|
new_email = NULL;
|
|
|
|
}
|
|
|
|
|
2014-11-25 03:44:14 +00:00
|
|
|
item = string_list_insert(map, old_email);
|
|
|
|
if (item->util) {
|
|
|
|
me = (struct mailmap_entry *)item->util;
|
2009-02-08 14:34:29 +00:00
|
|
|
} else {
|
2013-07-15 06:54:08 +00:00
|
|
|
me = xcalloc(1, sizeof(struct mailmap_entry));
|
|
|
|
me->namemap.strdup_strings = 1;
|
2013-09-12 15:37:08 +00:00
|
|
|
me->namemap.cmp = namemap_cmp;
|
2013-07-15 06:54:08 +00:00
|
|
|
item->util = me;
|
2009-02-08 14:34:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (old_name == NULL) {
|
2014-11-25 03:44:14 +00:00
|
|
|
debug_mm("mailmap: adding (simple) entry for '%s'\n", old_email);
|
|
|
|
|
2009-02-08 14:34:29 +00:00
|
|
|
/* Replace current name and new email for simple entry */
|
2010-10-11 15:41:16 +00:00
|
|
|
if (new_name) {
|
|
|
|
free(me->name);
|
2009-02-08 14:34:29 +00:00
|
|
|
me->name = xstrdup(new_name);
|
2010-10-11 15:41:16 +00:00
|
|
|
}
|
|
|
|
if (new_email) {
|
|
|
|
free(me->email);
|
2009-02-08 14:34:29 +00:00
|
|
|
me->email = xstrdup(new_email);
|
2010-10-11 15:41:16 +00:00
|
|
|
}
|
2009-02-08 14:34:29 +00:00
|
|
|
} else {
|
2011-11-17 01:25:06 +00:00
|
|
|
struct mailmap_info *mi = xcalloc(1, sizeof(struct mailmap_info));
|
2014-11-25 03:44:14 +00:00
|
|
|
debug_mm("mailmap: adding (complex) entry for '%s'\n", old_email);
|
2016-10-12 18:20:23 +00:00
|
|
|
mi->name = xstrdup_or_null(new_name);
|
|
|
|
mi->email = xstrdup_or_null(new_email);
|
2010-06-25 23:41:35 +00:00
|
|
|
string_list_insert(&me->namemap, old_name)->util = mi;
|
2009-02-08 14:34:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
debug_mm("mailmap: '%s' <%s> -> '%s' <%s>\n",
|
2013-07-15 06:54:13 +00:00
|
|
|
debug_str(old_name), old_email,
|
|
|
|
debug_str(new_name), debug_str(new_email));
|
2009-02-08 14:34:29 +00:00
|
|
|
}
|
|
|
|
|
2009-03-31 15:30:39 +00:00
|
|
|
static char *parse_name_and_email(char *buffer, char **name,
|
2013-07-15 06:54:13 +00:00
|
|
|
char **email, int allow_empty_email)
|
2009-02-08 14:34:29 +00:00
|
|
|
{
|
|
|
|
char *left, *right, *nstart, *nend;
|
2009-06-18 17:28:43 +00:00
|
|
|
*name = *email = NULL;
|
2009-02-08 14:34:29 +00:00
|
|
|
|
|
|
|
if ((left = strchr(buffer, '<')) == NULL)
|
|
|
|
return NULL;
|
|
|
|
if ((right = strchr(left+1, '>')) == NULL)
|
|
|
|
return NULL;
|
2009-03-31 15:30:39 +00:00
|
|
|
if (!allow_empty_email && (left+1 == right))
|
2009-02-08 14:34:29 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* remove whitespace from beginning and end of name */
|
|
|
|
nstart = buffer;
|
|
|
|
while (isspace(*nstart) && nstart < left)
|
|
|
|
++nstart;
|
|
|
|
nend = left-1;
|
2012-10-27 22:49:55 +00:00
|
|
|
while (nend > nstart && isspace(*nend))
|
2009-02-08 14:34:29 +00:00
|
|
|
--nend;
|
|
|
|
|
2013-07-15 06:54:06 +00:00
|
|
|
*name = (nstart <= nend ? nstart : NULL);
|
2009-02-08 14:34:29 +00:00
|
|
|
*email = left+1;
|
|
|
|
*(nend+1) = '\0';
|
|
|
|
*right++ = '\0';
|
|
|
|
|
|
|
|
return (*right == '\0' ? NULL : right);
|
|
|
|
}
|
|
|
|
|
2012-12-12 10:59:45 +00:00
|
|
|
static void read_mailmap_line(struct string_list *map, char *buffer,
|
|
|
|
char **repo_abbrev)
|
|
|
|
{
|
|
|
|
char *name1 = NULL, *email1 = NULL, *name2 = NULL, *email2 = NULL;
|
|
|
|
if (buffer[0] == '#') {
|
|
|
|
static const char abbrev[] = "# repo-abbrev:";
|
|
|
|
int abblen = sizeof(abbrev) - 1;
|
|
|
|
int len = strlen(buffer);
|
|
|
|
|
|
|
|
if (!repo_abbrev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (len && buffer[len - 1] == '\n')
|
|
|
|
buffer[--len] = 0;
|
|
|
|
if (!strncmp(buffer, abbrev, abblen)) {
|
|
|
|
char *cp;
|
|
|
|
|
2013-08-20 14:18:00 +00:00
|
|
|
free(*repo_abbrev);
|
2012-12-12 10:59:45 +00:00
|
|
|
|
|
|
|
for (cp = buffer + abblen; isspace(*cp); cp++)
|
|
|
|
; /* nothing */
|
2015-09-24 21:07:16 +00:00
|
|
|
*repo_abbrev = xstrdup(cp);
|
2012-12-12 10:59:45 +00:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if ((name2 = parse_name_and_email(buffer, &name1, &email1, 0)) != NULL)
|
|
|
|
parse_name_and_email(name2, &name2, &email2, 1);
|
|
|
|
|
|
|
|
if (email1)
|
|
|
|
add_mapping(map, name1, email1, name2, email2);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int read_mailmap_file(struct string_list *map, const char *filename,
|
|
|
|
char **repo_abbrev)
|
2007-04-27 07:41:15 +00:00
|
|
|
{
|
|
|
|
char buffer[1024];
|
mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:18:02 +00:00
|
|
|
FILE *f;
|
|
|
|
|
|
|
|
if (!filename)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
f = fopen(filename, "r");
|
|
|
|
if (!f) {
|
|
|
|
if (errno == ENOENT)
|
|
|
|
return 0;
|
2016-05-08 09:47:50 +00:00
|
|
|
return error_errno("unable to open mailmap at %s", filename);
|
mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:18:02 +00:00
|
|
|
}
|
2007-04-27 07:41:15 +00:00
|
|
|
|
2012-12-12 10:59:45 +00:00
|
|
|
while (fgets(buffer, sizeof(buffer), f) != NULL)
|
|
|
|
read_mailmap_line(map, buffer, repo_abbrev);
|
2007-04-27 07:41:15 +00:00
|
|
|
fclose(f);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
mailmap: handle mailmap blobs without trailing newlines
The read_mailmap_buf function reads each line of the mailmap
using strchrnul, like:
const char *end = strchrnul(buf, '\n');
unsigned long linelen = end - buf + 1;
But that's off-by-one when we actually hit the NUL byte; our
line does not have a terminator, and so is only "end - buf"
bytes long. As a result, when we subtract the linelen from
the total len, we end up with (unsigned long)-1 bytes left
in the buffer, and we start reading random junk from memory.
We could fix it with:
unsigned long linelen = end - buf + !!*end;
but let's take a step back for a moment. It's questionable
in the first place for a function that takes a buffer and
length to be using strchrnul. But it works because we only
have one caller (and are only likely to ever have this one),
which is handing us data from read_sha1_file. Which means
that it's always NUL-terminated.
Instead of tightening the assumptions to make the
buffer/length pair work for a caller that doesn't actually
exist, let's let loosen the assumptions to what the real
caller has: a modifiable, NUL-terminated string.
This makes the code simpler and shorter (because we don't
have to correlate strchrnul with the length calculation),
correct (because the code with the off-by-one just goes
away), and more efficient (we can drop the extra allocation
we needed to create NUL-terminated strings for each line,
and just terminate in place).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-28 01:41:39 +00:00
|
|
|
static void read_mailmap_string(struct string_list *map, char *buf,
|
|
|
|
char **repo_abbrev)
|
2012-12-12 11:04:04 +00:00
|
|
|
{
|
mailmap: handle mailmap blobs without trailing newlines
The read_mailmap_buf function reads each line of the mailmap
using strchrnul, like:
const char *end = strchrnul(buf, '\n');
unsigned long linelen = end - buf + 1;
But that's off-by-one when we actually hit the NUL byte; our
line does not have a terminator, and so is only "end - buf"
bytes long. As a result, when we subtract the linelen from
the total len, we end up with (unsigned long)-1 bytes left
in the buffer, and we start reading random junk from memory.
We could fix it with:
unsigned long linelen = end - buf + !!*end;
but let's take a step back for a moment. It's questionable
in the first place for a function that takes a buffer and
length to be using strchrnul. But it works because we only
have one caller (and are only likely to ever have this one),
which is handing us data from read_sha1_file. Which means
that it's always NUL-terminated.
Instead of tightening the assumptions to make the
buffer/length pair work for a caller that doesn't actually
exist, let's let loosen the assumptions to what the real
caller has: a modifiable, NUL-terminated string.
This makes the code simpler and shorter (because we don't
have to correlate strchrnul with the length calculation),
correct (because the code with the off-by-one just goes
away), and more efficient (we can drop the extra allocation
we needed to create NUL-terminated strings for each line,
and just terminate in place).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-28 01:41:39 +00:00
|
|
|
while (*buf) {
|
|
|
|
char *end = strchrnul(buf, '\n');
|
2012-12-12 11:04:04 +00:00
|
|
|
|
mailmap: handle mailmap blobs without trailing newlines
The read_mailmap_buf function reads each line of the mailmap
using strchrnul, like:
const char *end = strchrnul(buf, '\n');
unsigned long linelen = end - buf + 1;
But that's off-by-one when we actually hit the NUL byte; our
line does not have a terminator, and so is only "end - buf"
bytes long. As a result, when we subtract the linelen from
the total len, we end up with (unsigned long)-1 bytes left
in the buffer, and we start reading random junk from memory.
We could fix it with:
unsigned long linelen = end - buf + !!*end;
but let's take a step back for a moment. It's questionable
in the first place for a function that takes a buffer and
length to be using strchrnul. But it works because we only
have one caller (and are only likely to ever have this one),
which is handing us data from read_sha1_file. Which means
that it's always NUL-terminated.
Instead of tightening the assumptions to make the
buffer/length pair work for a caller that doesn't actually
exist, let's let loosen the assumptions to what the real
caller has: a modifiable, NUL-terminated string.
This makes the code simpler and shorter (because we don't
have to correlate strchrnul with the length calculation),
correct (because the code with the off-by-one just goes
away), and more efficient (we can drop the extra allocation
we needed to create NUL-terminated strings for each line,
and just terminate in place).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-28 01:41:39 +00:00
|
|
|
if (*end)
|
|
|
|
*end++ = '\0';
|
2012-12-12 11:04:04 +00:00
|
|
|
|
mailmap: handle mailmap blobs without trailing newlines
The read_mailmap_buf function reads each line of the mailmap
using strchrnul, like:
const char *end = strchrnul(buf, '\n');
unsigned long linelen = end - buf + 1;
But that's off-by-one when we actually hit the NUL byte; our
line does not have a terminator, and so is only "end - buf"
bytes long. As a result, when we subtract the linelen from
the total len, we end up with (unsigned long)-1 bytes left
in the buffer, and we start reading random junk from memory.
We could fix it with:
unsigned long linelen = end - buf + !!*end;
but let's take a step back for a moment. It's questionable
in the first place for a function that takes a buffer and
length to be using strchrnul. But it works because we only
have one caller (and are only likely to ever have this one),
which is handing us data from read_sha1_file. Which means
that it's always NUL-terminated.
Instead of tightening the assumptions to make the
buffer/length pair work for a caller that doesn't actually
exist, let's let loosen the assumptions to what the real
caller has: a modifiable, NUL-terminated string.
This makes the code simpler and shorter (because we don't
have to correlate strchrnul with the length calculation),
correct (because the code with the off-by-one just goes
away), and more efficient (we can drop the extra allocation
we needed to create NUL-terminated strings for each line,
and just terminate in place).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-28 01:41:39 +00:00
|
|
|
read_mailmap_line(map, buf, repo_abbrev);
|
|
|
|
buf = end;
|
2012-12-12 11:04:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int read_mailmap_blob(struct string_list *map,
|
|
|
|
const char *name,
|
|
|
|
char **repo_abbrev)
|
|
|
|
{
|
2017-07-13 23:49:27 +00:00
|
|
|
struct object_id oid;
|
2012-12-12 11:04:04 +00:00
|
|
|
char *buf;
|
|
|
|
unsigned long size;
|
|
|
|
enum object_type type;
|
|
|
|
|
|
|
|
if (!name)
|
mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:18:02 +00:00
|
|
|
return 0;
|
2017-07-13 23:49:27 +00:00
|
|
|
if (get_oid(name, &oid) < 0)
|
mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:18:02 +00:00
|
|
|
return 0;
|
2012-12-12 11:04:04 +00:00
|
|
|
|
2017-07-13 23:49:27 +00:00
|
|
|
buf = read_sha1_file(oid.hash, &type, &size);
|
2012-12-12 11:04:04 +00:00
|
|
|
if (!buf)
|
mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:18:02 +00:00
|
|
|
return error("unable to read mailmap object at %s", name);
|
2012-12-12 11:04:04 +00:00
|
|
|
if (type != OBJ_BLOB)
|
mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:18:02 +00:00
|
|
|
return error("mailmap is not a blob: %s", name);
|
2012-12-12 11:04:04 +00:00
|
|
|
|
mailmap: handle mailmap blobs without trailing newlines
The read_mailmap_buf function reads each line of the mailmap
using strchrnul, like:
const char *end = strchrnul(buf, '\n');
unsigned long linelen = end - buf + 1;
But that's off-by-one when we actually hit the NUL byte; our
line does not have a terminator, and so is only "end - buf"
bytes long. As a result, when we subtract the linelen from
the total len, we end up with (unsigned long)-1 bytes left
in the buffer, and we start reading random junk from memory.
We could fix it with:
unsigned long linelen = end - buf + !!*end;
but let's take a step back for a moment. It's questionable
in the first place for a function that takes a buffer and
length to be using strchrnul. But it works because we only
have one caller (and are only likely to ever have this one),
which is handing us data from read_sha1_file. Which means
that it's always NUL-terminated.
Instead of tightening the assumptions to make the
buffer/length pair work for a caller that doesn't actually
exist, let's let loosen the assumptions to what the real
caller has: a modifiable, NUL-terminated string.
This makes the code simpler and shorter (because we don't
have to correlate strchrnul with the length calculation),
correct (because the code with the off-by-one just goes
away), and more efficient (we can drop the extra allocation
we needed to create NUL-terminated strings for each line,
and just terminate in place).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-28 01:41:39 +00:00
|
|
|
read_mailmap_string(map, buf, repo_abbrev);
|
2012-12-12 11:04:04 +00:00
|
|
|
|
|
|
|
free(buf);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-02-08 14:34:27 +00:00
|
|
|
int read_mailmap(struct string_list *map, char **repo_abbrev)
|
|
|
|
{
|
mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:18:02 +00:00
|
|
|
int err = 0;
|
mailmap: default mailmap.blob in bare repositories
The motivation for mailmap.blob is to let users of bare
repositories use the mailmap feature, as they would not have
a checkout containing the .mailmap file. We can make it even
easier for them by just looking in HEAD:.mailmap by default.
We can't know for sure that this is where they would keep a
mailmap, of course, but it is the best guess (and it matches
the non-bare behavior, which reads from HEAD:.mailmap in the
working tree). If it's missing, git will silently ignore the
setting.
We do not do the same magic in the non-bare case, because:
1. In the common case, HEAD:.mailmap will be the same as
the .mailmap in the working tree, which is a no-op.
2. In the uncommon case, the user has modified .mailmap
but not yet committed it, and would expect the working
tree version to take precedence.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-13 13:04:47 +00:00
|
|
|
|
2009-02-08 14:34:29 +00:00
|
|
|
map->strdup_strings = 1;
|
2013-09-12 15:37:08 +00:00
|
|
|
map->cmp = namemap_cmp;
|
mailmap: default mailmap.blob in bare repositories
The motivation for mailmap.blob is to let users of bare
repositories use the mailmap feature, as they would not have
a checkout containing the .mailmap file. We can make it even
easier for them by just looking in HEAD:.mailmap by default.
We can't know for sure that this is where they would keep a
mailmap, of course, but it is the best guess (and it matches
the non-bare behavior, which reads from HEAD:.mailmap in the
working tree). If it's missing, git will silently ignore the
setting.
We do not do the same magic in the non-bare case, because:
1. In the common case, HEAD:.mailmap will be the same as
the .mailmap in the working tree, which is a no-op.
2. In the uncommon case, the user has modified .mailmap
but not yet committed it, and would expect the working
tree version to take precedence.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-13 13:04:47 +00:00
|
|
|
|
|
|
|
if (!git_mailmap_blob && is_bare_repository())
|
|
|
|
git_mailmap_blob = "HEAD:.mailmap";
|
|
|
|
|
mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:18:02 +00:00
|
|
|
err |= read_mailmap_file(map, ".mailmap", repo_abbrev);
|
2016-03-05 22:13:29 +00:00
|
|
|
if (startup_info->have_repository)
|
|
|
|
err |= read_mailmap_blob(map, git_mailmap_blob, repo_abbrev);
|
mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:18:02 +00:00
|
|
|
err |= read_mailmap_file(map, git_mailmap_file, repo_abbrev);
|
|
|
|
return err;
|
2009-02-08 14:34:27 +00:00
|
|
|
}
|
|
|
|
|
2009-02-08 14:34:29 +00:00
|
|
|
void clear_mailmap(struct string_list *map)
|
|
|
|
{
|
|
|
|
debug_mm("mailmap: clearing %d entries...\n", map->nr);
|
|
|
|
map->strdup_strings = 1;
|
|
|
|
string_list_clear_func(map, free_mailmap_entry);
|
|
|
|
debug_mm("mailmap: cleared\n");
|
|
|
|
}
|
|
|
|
|
mailmap: remove email copy and length limitation
In map_user(), we have email pointer that points at the beginning of
an e-mail address, but the buffer is not terminated with a NUL after
the e-mail address. It typically has ">" after the address, and it
could have even more if it comes from author/committer line in a
commit object. Or it may not have ">" after it.
We used to copy the e-mail address proper into a temporary buffer
before asking the string-list API to find the e-mail address in the
mailmap, because string_list_lookup() function only takes a NUL
terminated full string.
Introduce a helper function lookup_prefix that takes the email
pointer and the length, and finds a matching entry in the string
list used for the mailmap, by doing the following:
- First ask string_list_find_insert_index() where in its sorted
list the e-mail address we have (including the possible trailing
junk ">...") would be inserted.
- It could find an exact match (e.g. we had a clean e-mail address
without any trailing junk). We can return the item in that case.
- Or it could return the index of an item that sorts after the
e-mail address we have.
- If we did not find an exact match against a clean e-mail address,
then the record we are looking for in the mailmap has to exist
before the index returned by the function (i.e. "email>junk"
always sorts later than "email"). Iterate, starting from that
index, down the map->items[] array until we find the exact record
we are looking for, or we see a record with a key that definitely
sorts earlier than the e-mail we are looking for (i.e. when we
are looking for "email" in "email>junk", a record in the mailmap
that begins with "emaik" strictly sorts before "email", if such a
key existed in the mailmap).
This, together with the earlier enhancement to support
case-insensitive sorting, allow us to remove an extra copy of email
buffer to downcase it.
A part of this is based on Antoine Pelisse's previous work.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-05 21:26:39 +00:00
|
|
|
/*
|
|
|
|
* Look for an entry in map that match string[0:len]; string[len]
|
|
|
|
* does not have to be NUL (but it could be).
|
|
|
|
*/
|
|
|
|
static struct string_list_item *lookup_prefix(struct string_list *map,
|
|
|
|
const char *string, size_t len)
|
|
|
|
{
|
|
|
|
int i = string_list_find_insert_index(map, string, 1);
|
|
|
|
if (i < 0) {
|
|
|
|
/* exact match */
|
|
|
|
i = -1 - i;
|
|
|
|
if (!string[len])
|
|
|
|
return &map->items[i];
|
|
|
|
/*
|
|
|
|
* that map entry matches exactly to the string, including
|
|
|
|
* the cruft at the end beyond "len". That is not a match
|
|
|
|
* with string[0:len] that we are looking for.
|
|
|
|
*/
|
|
|
|
} else if (!string[len]) {
|
|
|
|
/*
|
|
|
|
* asked with the whole string, and got nothing. No
|
|
|
|
* matching entry can exist in the map.
|
|
|
|
*/
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* i is at the exact match to an overlong key, or location the
|
|
|
|
* overlong key would be inserted, which must come after the
|
|
|
|
* real location of the key if one exists.
|
|
|
|
*/
|
|
|
|
while (0 <= --i && i < map->nr) {
|
|
|
|
int cmp = strncasecmp(map->items[i].string, string, len);
|
|
|
|
if (cmp < 0)
|
|
|
|
/*
|
|
|
|
* "i" points at a key definitely below the prefix;
|
|
|
|
* the map does not have string[0:len] in it.
|
|
|
|
*/
|
|
|
|
break;
|
|
|
|
else if (!cmp && !map->items[i].string[len])
|
|
|
|
/* found it */
|
|
|
|
return &map->items[i];
|
|
|
|
/*
|
|
|
|
* otherwise, the string at "i" may be string[0:len]
|
|
|
|
* followed by a string that sorts later than string[len:];
|
|
|
|
* keep trying.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2009-02-08 14:34:29 +00:00
|
|
|
int map_user(struct string_list *map,
|
2013-07-15 06:54:13 +00:00
|
|
|
const char **email, size_t *emaillen,
|
|
|
|
const char **name, size_t *namelen)
|
2007-04-27 07:41:15 +00:00
|
|
|
{
|
2008-07-21 18:03:49 +00:00
|
|
|
struct string_list_item *item;
|
2009-02-08 14:34:29 +00:00
|
|
|
struct mailmap_entry *me;
|
mailmap: remove email copy and length limitation
In map_user(), we have email pointer that points at the beginning of
an e-mail address, but the buffer is not terminated with a NUL after
the e-mail address. It typically has ">" after the address, and it
could have even more if it comes from author/committer line in a
commit object. Or it may not have ">" after it.
We used to copy the e-mail address proper into a temporary buffer
before asking the string-list API to find the e-mail address in the
mailmap, because string_list_lookup() function only takes a NUL
terminated full string.
Introduce a helper function lookup_prefix that takes the email
pointer and the length, and finds a matching entry in the string
list used for the mailmap, by doing the following:
- First ask string_list_find_insert_index() where in its sorted
list the e-mail address we have (including the possible trailing
junk ">...") would be inserted.
- It could find an exact match (e.g. we had a clean e-mail address
without any trailing junk). We can return the item in that case.
- Or it could return the index of an item that sorts after the
e-mail address we have.
- If we did not find an exact match against a clean e-mail address,
then the record we are looking for in the mailmap has to exist
before the index returned by the function (i.e. "email>junk"
always sorts later than "email"). Iterate, starting from that
index, down the map->items[] array until we find the exact record
we are looking for, or we see a record with a key that definitely
sorts earlier than the e-mail we are looking for (i.e. when we
are looking for "email" in "email>junk", a record in the mailmap
that begins with "emaik" strictly sorts before "email", if such a
key existed in the mailmap).
This, together with the earlier enhancement to support
case-insensitive sorting, allow us to remove an extra copy of email
buffer to downcase it.
A part of this is based on Antoine Pelisse's previous work.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-05 21:26:39 +00:00
|
|
|
|
2013-01-05 21:26:40 +00:00
|
|
|
debug_mm("map_user: map '%.*s' <%.*s>\n",
|
2013-07-15 06:54:13 +00:00
|
|
|
(int)*namelen, debug_str(*name),
|
|
|
|
(int)*emaillen, debug_str(*email));
|
mailmap: remove email copy and length limitation
In map_user(), we have email pointer that points at the beginning of
an e-mail address, but the buffer is not terminated with a NUL after
the e-mail address. It typically has ">" after the address, and it
could have even more if it comes from author/committer line in a
commit object. Or it may not have ">" after it.
We used to copy the e-mail address proper into a temporary buffer
before asking the string-list API to find the e-mail address in the
mailmap, because string_list_lookup() function only takes a NUL
terminated full string.
Introduce a helper function lookup_prefix that takes the email
pointer and the length, and finds a matching entry in the string
list used for the mailmap, by doing the following:
- First ask string_list_find_insert_index() where in its sorted
list the e-mail address we have (including the possible trailing
junk ">...") would be inserted.
- It could find an exact match (e.g. we had a clean e-mail address
without any trailing junk). We can return the item in that case.
- Or it could return the index of an item that sorts after the
e-mail address we have.
- If we did not find an exact match against a clean e-mail address,
then the record we are looking for in the mailmap has to exist
before the index returned by the function (i.e. "email>junk"
always sorts later than "email"). Iterate, starting from that
index, down the map->items[] array until we find the exact record
we are looking for, or we see a record with a key that definitely
sorts earlier than the e-mail we are looking for (i.e. when we
are looking for "email" in "email>junk", a record in the mailmap
that begins with "emaik" strictly sorts before "email", if such a
key existed in the mailmap).
This, together with the earlier enhancement to support
case-insensitive sorting, allow us to remove an extra copy of email
buffer to downcase it.
A part of this is based on Antoine Pelisse's previous work.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-05 21:26:39 +00:00
|
|
|
|
2013-01-05 21:26:40 +00:00
|
|
|
item = lookup_prefix(map, *email, *emaillen);
|
2009-02-08 14:34:29 +00:00
|
|
|
if (item != NULL) {
|
|
|
|
me = (struct mailmap_entry *)item->util;
|
|
|
|
if (me->namemap.nr) {
|
2013-07-15 06:54:13 +00:00
|
|
|
/*
|
|
|
|
* The item has multiple items, so we'll look up on
|
|
|
|
* name too. If the name is not found, we choose the
|
|
|
|
* simple entry.
|
|
|
|
*/
|
2013-01-05 21:26:40 +00:00
|
|
|
struct string_list_item *subitem;
|
|
|
|
subitem = lookup_prefix(&me->namemap, *name, *namelen);
|
2009-02-08 14:34:29 +00:00
|
|
|
if (subitem)
|
|
|
|
item = subitem;
|
|
|
|
}
|
|
|
|
}
|
2007-04-27 07:41:15 +00:00
|
|
|
if (item != NULL) {
|
2009-02-08 14:34:29 +00:00
|
|
|
struct mailmap_info *mi = (struct mailmap_info *)item->util;
|
2013-01-05 21:26:40 +00:00
|
|
|
if (mi->name == NULL && mi->email == NULL) {
|
2009-02-08 14:34:29 +00:00
|
|
|
debug_mm("map_user: -- (no simple mapping)\n");
|
|
|
|
return 0;
|
|
|
|
}
|
2013-01-05 21:26:40 +00:00
|
|
|
if (mi->email) {
|
|
|
|
*email = mi->email;
|
|
|
|
*emaillen = strlen(*email);
|
|
|
|
}
|
|
|
|
if (mi->name) {
|
|
|
|
*name = mi->name;
|
|
|
|
*namelen = strlen(*name);
|
|
|
|
}
|
2013-07-15 06:54:13 +00:00
|
|
|
debug_mm("map_user: to '%.*s' <%.*s>\n",
|
|
|
|
(int)*namelen, debug_str(*name),
|
|
|
|
(int)*emaillen, debug_str(*email));
|
2007-04-27 07:41:15 +00:00
|
|
|
return 1;
|
|
|
|
}
|
2009-02-08 14:34:29 +00:00
|
|
|
debug_mm("map_user: --\n");
|
2007-04-27 07:41:15 +00:00
|
|
|
return 0;
|
|
|
|
}
|