global: introduce `USE_THE_REPOSITORY_VARIABLE` macro
Use of the `the_repository` variable is deprecated nowadays, and we
slowly but steadily convert the codebase to not use it anymore. Instead,
callers should be passing down the repository to work on via parameters.
It is hard though to prove that a given code unit does not use this
variable anymore. The most trivial case, merely demonstrating that there
is no direct use of `the_repository`, is already a bit of a pain during
code reviews as the reviewer needs to manually verify claims made by the
patch author. The bigger problem though is that we have many interfaces
that implicitly rely on `the_repository`.
Introduce a new `USE_THE_REPOSITORY_VARIABLE` macro that allows code
units to opt into usage of `the_repository`. The intent of this macro is
to demonstrate that a certain code unit does not use this variable
anymore, and to keep it from new dependencies on it in future changes,
be it explicit or implicit
For now, the macro only guards `the_repository` itself as well as
`the_hash_algo`. There are many more known interfaces where we have an
implicit dependency on `the_repository`, but those are not guarded at
the current point in time. Over time though, we should start to add
guards as required (or even better, just remove them).
Define the macro as required in our code units. As expected, most of our
code still relies on the global variable. Nearly all of our builtins
rely on the variable as there is no way yet to pass `the_repository` to
their entry point. For now, declare the macro in "biultin.h" to keep the
required changes at least a little bit more contained.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-14 14:50:23 +08:00
|
|
|
#define USE_THE_REPOSITORY_VARIABLE
|
|
|
|
|
2023-04-11 15:41:50 +08:00
|
|
|
#include "git-compat-util.h"
|
2023-03-21 14:26:03 +08:00
|
|
|
#include "environment.h"
|
2008-07-22 02:03:49 +08:00
|
|
|
#include "string-list.h"
|
2007-05-01 06:31:52 +08:00
|
|
|
#include "mailmap.h"
|
2023-04-11 15:41:49 +08:00
|
|
|
#include "object-name.h"
|
2023-05-16 14:34:06 +08:00
|
|
|
#include "object-store-ll.h"
|
2023-03-21 14:26:05 +08:00
|
|
|
#include "setup.h"
|
2007-04-27 15:41:15 +08:00
|
|
|
|
2024-05-27 19:46:15 +08:00
|
|
|
char *git_mailmap_file;
|
2024-05-27 19:46:39 +08:00
|
|
|
char *git_mailmap_blob;
|
2009-02-08 22:34:29 +08: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;
|
|
|
|
};
|
|
|
|
|
mailmap: drop debugging code
There's some debugging code in mailmap.c which is only compiled if you
manually tweak the source to set DEBUG_MAILMAP. When it's not set, the
fallback noop uses static inline functions; we couldn't use macros here
because one of the functions is variadic (and variadic macros were
forbidden back then, but aren't now). As a result, this triggers
a -Wunused-parameter warning.
We have a few options here:
1. Leave it be. Just mark it as UNUSED, or switch to a variadic macro.
2. Assume the debugging code is useful, compile it always, and trigger
it with a run-time flag (e.g., with a trace key). This is pretty
easy to do, and carries a pretty small runtime cost.
3. Assume the debugging is not very useful, and just rip it out. This
matches what we did with a similar case in 69c5f17f11 (attr: drop
DEBUG_ATTR code, 2022-10-06).
The debugging flag has been mentioned only three times on the list.
Once, when it was added in 2009:
https://lore.kernel.org/git/cover.1234102794.git.marius@trolltech.com/
In 2013, when somebody fixed some compilation errors in the conditional
code (presumably because they used it while making other changes):
https://lore.kernel.org/git/1373871253-96480-1-git-send-email-sunshine@sunshineco.com/
And finally it seemed to have been useful to somebody in 2020:
https://lore.kernel.org/git/87eejswql6.fsf@evledraar.gmail.com/
So it's not totally without value. On the other hand, it's not likely to
be useful to non-developers (and certainly isn't if you have to
recompile). And using a debugger or adding your own inspection code is
likely to be as useful. So I've just dropped the code entirely here.
Note that we do still have to mark a few parameters unused in callback
functions which are passed to string_list_clear_func(). Those get an
extra pointer with the string being cleared, which we previously fed to
the debugging code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-18 03:16:26 +08:00
|
|
|
static void free_mailmap_info(void *p, const char *s UNUSED)
|
2009-02-08 22:34:29 +08:00
|
|
|
{
|
|
|
|
struct mailmap_info *mi = (struct mailmap_info *)p;
|
|
|
|
free(mi->name);
|
|
|
|
free(mi->email);
|
2021-08-31 21:42:52 +08:00
|
|
|
free(mi);
|
2009-02-08 22:34:29 +08:00
|
|
|
}
|
|
|
|
|
mailmap: drop debugging code
There's some debugging code in mailmap.c which is only compiled if you
manually tweak the source to set DEBUG_MAILMAP. When it's not set, the
fallback noop uses static inline functions; we couldn't use macros here
because one of the functions is variadic (and variadic macros were
forbidden back then, but aren't now). As a result, this triggers
a -Wunused-parameter warning.
We have a few options here:
1. Leave it be. Just mark it as UNUSED, or switch to a variadic macro.
2. Assume the debugging code is useful, compile it always, and trigger
it with a run-time flag (e.g., with a trace key). This is pretty
easy to do, and carries a pretty small runtime cost.
3. Assume the debugging is not very useful, and just rip it out. This
matches what we did with a similar case in 69c5f17f11 (attr: drop
DEBUG_ATTR code, 2022-10-06).
The debugging flag has been mentioned only three times on the list.
Once, when it was added in 2009:
https://lore.kernel.org/git/cover.1234102794.git.marius@trolltech.com/
In 2013, when somebody fixed some compilation errors in the conditional
code (presumably because they used it while making other changes):
https://lore.kernel.org/git/1373871253-96480-1-git-send-email-sunshine@sunshineco.com/
And finally it seemed to have been useful to somebody in 2020:
https://lore.kernel.org/git/87eejswql6.fsf@evledraar.gmail.com/
So it's not totally without value. On the other hand, it's not likely to
be useful to non-developers (and certainly isn't if you have to
recompile). And using a debugger or adding your own inspection code is
likely to be as useful. So I've just dropped the code entirely here.
Note that we do still have to mark a few parameters unused in callback
functions which are passed to string_list_clear_func(). Those get an
extra pointer with the string being cleared, which we previously fed to
the debugging code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-18 03:16:26 +08:00
|
|
|
static void free_mailmap_entry(void *p, const char *s UNUSED)
|
2009-02-08 22:34:29 +08:00
|
|
|
{
|
|
|
|
struct mailmap_entry *me = (struct mailmap_entry *)p;
|
2013-07-15 14:54:12 +08:00
|
|
|
|
2009-02-08 22:34:29 +08:00
|
|
|
free(me->name);
|
|
|
|
free(me->email);
|
|
|
|
|
|
|
|
me->namemap.strdup_strings = 1;
|
|
|
|
string_list_clear_func(&me->namemap, free_mailmap_info);
|
2021-08-31 21:42:52 +08:00
|
|
|
free(me);
|
2009-02-08 22:34:29 +08:00
|
|
|
}
|
|
|
|
|
2013-09-12 23:37:08 +08: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 22:34:29 +08:00
|
|
|
static void add_mapping(struct string_list *map,
|
2013-07-15 14:54:13 +08:00
|
|
|
char *new_name, char *new_email,
|
|
|
|
char *old_name, char *old_email)
|
2009-02-08 22:34:29 +08:00
|
|
|
{
|
|
|
|
struct mailmap_entry *me;
|
2014-11-25 11:44:14 +08:00
|
|
|
struct string_list_item *item;
|
2009-03-31 08:18:36 +08:00
|
|
|
|
2022-05-03 00:50:37 +08:00
|
|
|
if (!old_email) {
|
2009-02-08 22:34:29 +08:00
|
|
|
old_email = new_email;
|
|
|
|
new_email = NULL;
|
|
|
|
}
|
|
|
|
|
2014-11-25 11:44:14 +08:00
|
|
|
item = string_list_insert(map, old_email);
|
|
|
|
if (item->util) {
|
|
|
|
me = (struct mailmap_entry *)item->util;
|
2009-02-08 22:34:29 +08:00
|
|
|
} else {
|
2021-03-14 00:17:22 +08:00
|
|
|
CALLOC_ARRAY(me, 1);
|
2013-07-15 14:54:08 +08:00
|
|
|
me->namemap.strdup_strings = 1;
|
2013-09-12 23:37:08 +08:00
|
|
|
me->namemap.cmp = namemap_cmp;
|
2013-07-15 14:54:08 +08:00
|
|
|
item->util = me;
|
2009-02-08 22:34:29 +08:00
|
|
|
}
|
|
|
|
|
2022-05-03 00:50:37 +08:00
|
|
|
if (!old_name) {
|
2009-02-08 22:34:29 +08:00
|
|
|
/* Replace current name and new email for simple entry */
|
2010-10-11 23:41:16 +08:00
|
|
|
if (new_name) {
|
|
|
|
free(me->name);
|
2009-02-08 22:34:29 +08:00
|
|
|
me->name = xstrdup(new_name);
|
2010-10-11 23:41:16 +08:00
|
|
|
}
|
|
|
|
if (new_email) {
|
|
|
|
free(me->email);
|
2009-02-08 22:34:29 +08:00
|
|
|
me->email = xstrdup(new_email);
|
2010-10-11 23:41:16 +08:00
|
|
|
}
|
2009-02-08 22:34:29 +08:00
|
|
|
} else {
|
2011-11-17 09:25:06 +08:00
|
|
|
struct mailmap_info *mi = xcalloc(1, sizeof(struct mailmap_info));
|
2016-10-13 02:20:23 +08:00
|
|
|
mi->name = xstrdup_or_null(new_name);
|
|
|
|
mi->email = xstrdup_or_null(new_email);
|
2010-06-26 07:41:35 +08:00
|
|
|
string_list_insert(&me->namemap, old_name)->util = mi;
|
2009-02-08 22:34:29 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-03-31 23:30:39 +08:00
|
|
|
static char *parse_name_and_email(char *buffer, char **name,
|
2013-07-15 14:54:13 +08:00
|
|
|
char **email, int allow_empty_email)
|
2009-02-08 22:34:29 +08:00
|
|
|
{
|
|
|
|
char *left, *right, *nstart, *nend;
|
2009-06-19 01:28:43 +08:00
|
|
|
*name = *email = NULL;
|
2009-02-08 22:34:29 +08:00
|
|
|
|
2022-05-03 00:50:37 +08:00
|
|
|
if (!(left = strchr(buffer, '<')))
|
2009-02-08 22:34:29 +08:00
|
|
|
return NULL;
|
2022-05-03 00:50:37 +08:00
|
|
|
if (!(right = strchr(left + 1, '>')))
|
2009-02-08 22:34:29 +08:00
|
|
|
return NULL;
|
2009-03-31 23:30:39 +08:00
|
|
|
if (!allow_empty_email && (left+1 == right))
|
2009-02-08 22:34:29 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* remove whitespace from beginning and end of name */
|
|
|
|
nstart = buffer;
|
|
|
|
while (isspace(*nstart) && nstart < left)
|
|
|
|
++nstart;
|
|
|
|
nend = left-1;
|
2012-10-28 06:49:55 +08:00
|
|
|
while (nend > nstart && isspace(*nend))
|
2009-02-08 22:34:29 +08:00
|
|
|
--nend;
|
|
|
|
|
2013-07-15 14:54:06 +08:00
|
|
|
*name = (nstart <= nend ? nstart : NULL);
|
2009-02-08 22:34:29 +08:00
|
|
|
*email = left+1;
|
|
|
|
*(nend+1) = '\0';
|
|
|
|
*right++ = '\0';
|
|
|
|
|
|
|
|
return (*right == '\0' ? NULL : right);
|
|
|
|
}
|
|
|
|
|
2021-01-13 04:18:06 +08:00
|
|
|
static void read_mailmap_line(struct string_list *map, char *buffer)
|
2012-12-12 18:59:45 +08:00
|
|
|
{
|
|
|
|
char *name1 = NULL, *email1 = NULL, *name2 = NULL, *email2 = NULL;
|
|
|
|
|
2021-01-13 04:18:06 +08:00
|
|
|
if (buffer[0] == '#')
|
2012-12-12 18:59:45 +08:00
|
|
|
return;
|
2021-01-13 04:18:06 +08:00
|
|
|
|
2022-05-03 00:50:37 +08:00
|
|
|
if ((name2 = parse_name_and_email(buffer, &name1, &email1, 0)))
|
2012-12-12 18:59:45 +08:00
|
|
|
parse_name_and_email(name2, &name2, &email2, 1);
|
|
|
|
|
|
|
|
if (email1)
|
|
|
|
add_mapping(map, name1, email1, name2, email2);
|
|
|
|
}
|
|
|
|
|
2024-08-28 05:27:17 +08:00
|
|
|
int read_mailmap_file(struct string_list *map, const char *filename,
|
|
|
|
unsigned flags)
|
2007-04-27 15:41:15 +08: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 19:18:02 +08:00
|
|
|
FILE *f;
|
2021-02-16 22:44:37 +08:00
|
|
|
int fd;
|
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 19:18:02 +08:00
|
|
|
|
|
|
|
if (!filename)
|
|
|
|
return 0;
|
|
|
|
|
2021-02-16 22:44:37 +08:00
|
|
|
if (flags & MAILMAP_NOFOLLOW)
|
|
|
|
fd = open_nofollow(filename, O_RDONLY);
|
|
|
|
else
|
|
|
|
fd = open(filename, O_RDONLY);
|
|
|
|
|
|
|
|
if (fd < 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 19:18:02 +08:00
|
|
|
if (errno == ENOENT)
|
|
|
|
return 0;
|
2016-05-08 17:47:50 +08: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 19:18:02 +08:00
|
|
|
}
|
2021-02-16 22:44:37 +08:00
|
|
|
f = xfdopen(fd, "r");
|
2007-04-27 15:41:15 +08:00
|
|
|
|
2012-12-12 18:59:45 +08:00
|
|
|
while (fgets(buffer, sizeof(buffer), f) != NULL)
|
2021-01-13 04:18:06 +08:00
|
|
|
read_mailmap_line(map, buffer);
|
2007-04-27 15:41:15 +08:00
|
|
|
fclose(f);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-01-13 04:18:06 +08:00
|
|
|
static void read_mailmap_string(struct string_list *map, char *buf)
|
2012-12-12 19:04:04 +08: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 09:41:39 +08:00
|
|
|
while (*buf) {
|
|
|
|
char *end = strchrnul(buf, '\n');
|
2012-12-12 19:04:04 +08: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 09:41:39 +08:00
|
|
|
if (*end)
|
|
|
|
*end++ = '\0';
|
2012-12-12 19:04:04 +08:00
|
|
|
|
2021-01-13 04:18:06 +08:00
|
|
|
read_mailmap_line(map, buf);
|
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 09:41:39 +08:00
|
|
|
buf = end;
|
2012-12-12 19:04:04 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-08-28 05:27:17 +08:00
|
|
|
int read_mailmap_blob(struct string_list *map, const char *name)
|
2012-12-12 19:04:04 +08:00
|
|
|
{
|
2017-07-14 07:49:27 +08:00
|
|
|
struct object_id oid;
|
2012-12-12 19:04:04 +08: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 19:18:02 +08:00
|
|
|
return 0;
|
2023-03-28 21:58:46 +08:00
|
|
|
if (repo_get_oid(the_repository, 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 19:18:02 +08:00
|
|
|
return 0;
|
2012-12-12 19:04:04 +08:00
|
|
|
|
2023-03-28 21:58:50 +08:00
|
|
|
buf = repo_read_object_file(the_repository, &oid, &type, &size);
|
2012-12-12 19:04:04 +08: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 19:18:02 +08:00
|
|
|
return error("unable to read mailmap object at %s", name);
|
2024-07-26 07:12:41 +08:00
|
|
|
if (type != OBJ_BLOB) {
|
|
|
|
free(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 19:18:02 +08:00
|
|
|
return error("mailmap is not a blob: %s", name);
|
2024-07-26 07:12:41 +08:00
|
|
|
}
|
2012-12-12 19:04:04 +08:00
|
|
|
|
2021-01-13 04:18:06 +08:00
|
|
|
read_mailmap_string(map, buf);
|
2012-12-12 19:04:04 +08:00
|
|
|
|
|
|
|
free(buf);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-01-13 04:18:06 +08:00
|
|
|
int read_mailmap(struct string_list *map)
|
2009-02-08 22:34:27 +08:00
|
|
|
{
|
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 19:18:02 +08: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 21:04:47 +08:00
|
|
|
|
2009-02-08 22:34:29 +08:00
|
|
|
map->strdup_strings = 1;
|
2013-09-12 23:37:08 +08: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 21:04:47 +08:00
|
|
|
|
|
|
|
if (!git_mailmap_blob && is_bare_repository())
|
2024-06-07 14:39:12 +08:00
|
|
|
git_mailmap_blob = xstrdup("HEAD:.mailmap");
|
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 21:04:47 +08:00
|
|
|
|
mailmap: only look for .mailmap in work tree
When trying to find a .mailmap file, we will always look for it in the
current directory. This makes sense in a repository with a working tree,
since we'd always go to the toplevel directory at startup. But for a
bare repository, it can be confusing. With an option like --git-dir (or
$GIT_DIR in the environment), we don't chdir at all, and we'd read
.mailmap from whatever directory you happened to be in before starting
Git.
(Note that --git-dir without specifying a working tree historically
means "the current directory is the root of the working tree", but most
bare repositories will have core.bare set these days, meaning they will
realize there is no working tree at all).
The documentation for gitmailmap(5) says:
If the file `.mailmap` exists at the toplevel of the repository[...]
which likewise reinforces the notion that we are looking in the working
tree.
This patch prevents us from looking for such a file when we're in a bare
repository. This does break something that used to work:
cd bare.git
git cat-file blob HEAD:.mailmap >.mailmap
git shortlog
But that was never advertised in the documentation. And these days we
have mailmap.blob (which defaults to HEAD:.mailmap) to do the same thing
in a much cleaner way.
However, there's one more interesting case: we might not have a
repository at all! The git-shortlog command can be run with git-log
output fed on its stdin, and it will apply the mailmap. In that case, it
probably does make sense to read .mailmap from the current directory.
This patch will continue to do so.
That leads to one even weirder case: if you run git-shortlog to process
stdin, the input _could_ be from a different repository entirely. Should
we respect the in-tree .mailmap then? Probably yes. Whatever the source
of the input, if shortlog is running in a repository, the documentation
claims that we'd read the .mailmap from its top-level (and of course
it's reasonably likely that it _is_ from the same repo, and the user
just preferred to run git-log and git-shortlog separately for whatever
reason).
The included test covers these cases, and we now document the "no repo"
case explicitly.
We also add a test that confirms we find a top-level ".mailmap" even
when we start in a subdirectory of the working tree. This worked both
before and after this commit, but we never tested it explicitly (it
works because we always chdir to the top-level of the working tree if
there is one).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-11 04:34:33 +08:00
|
|
|
if (!startup_info->have_repository || !is_bare_repository())
|
2021-03-23 05:00:22 +08:00
|
|
|
err |= read_mailmap_file(map, ".mailmap",
|
|
|
|
startup_info->have_repository ?
|
|
|
|
MAILMAP_NOFOLLOW : 0);
|
2016-03-06 06:13:29 +08:00
|
|
|
if (startup_info->have_repository)
|
2021-01-13 04:18:06 +08:00
|
|
|
err |= read_mailmap_blob(map, git_mailmap_blob);
|
2021-02-16 22:44:37 +08:00
|
|
|
err |= read_mailmap_file(map, git_mailmap_file, 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 19:18:02 +08:00
|
|
|
return err;
|
2009-02-08 22:34:27 +08:00
|
|
|
}
|
|
|
|
|
2009-02-08 22:34:29 +08:00
|
|
|
void clear_mailmap(struct string_list *map)
|
|
|
|
{
|
|
|
|
map->strdup_strings = 1;
|
|
|
|
string_list_clear_func(map, free_mailmap_entry);
|
|
|
|
}
|
|
|
|
|
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-06 05:26:39 +08: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 22:34:29 +08:00
|
|
|
int map_user(struct string_list *map,
|
2013-07-15 14:54:13 +08:00
|
|
|
const char **email, size_t *emaillen,
|
|
|
|
const char **name, size_t *namelen)
|
2007-04-27 15:41:15 +08:00
|
|
|
{
|
2008-07-22 02:03:49 +08:00
|
|
|
struct string_list_item *item;
|
2009-02-08 22:34:29 +08: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-06 05:26:39 +08:00
|
|
|
|
2013-01-06 05:26:40 +08:00
|
|
|
item = lookup_prefix(map, *email, *emaillen);
|
2022-05-03 00:50:37 +08:00
|
|
|
if (item) {
|
2009-02-08 22:34:29 +08:00
|
|
|
me = (struct mailmap_entry *)item->util;
|
|
|
|
if (me->namemap.nr) {
|
2013-07-15 14:54:13 +08: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-06 05:26:40 +08:00
|
|
|
struct string_list_item *subitem;
|
|
|
|
subitem = lookup_prefix(&me->namemap, *name, *namelen);
|
2009-02-08 22:34:29 +08:00
|
|
|
if (subitem)
|
|
|
|
item = subitem;
|
|
|
|
}
|
|
|
|
}
|
2022-05-03 00:50:37 +08:00
|
|
|
if (item) {
|
2009-02-08 22:34:29 +08:00
|
|
|
struct mailmap_info *mi = (struct mailmap_info *)item->util;
|
mailmap: drop debugging code
There's some debugging code in mailmap.c which is only compiled if you
manually tweak the source to set DEBUG_MAILMAP. When it's not set, the
fallback noop uses static inline functions; we couldn't use macros here
because one of the functions is variadic (and variadic macros were
forbidden back then, but aren't now). As a result, this triggers
a -Wunused-parameter warning.
We have a few options here:
1. Leave it be. Just mark it as UNUSED, or switch to a variadic macro.
2. Assume the debugging code is useful, compile it always, and trigger
it with a run-time flag (e.g., with a trace key). This is pretty
easy to do, and carries a pretty small runtime cost.
3. Assume the debugging is not very useful, and just rip it out. This
matches what we did with a similar case in 69c5f17f11 (attr: drop
DEBUG_ATTR code, 2022-10-06).
The debugging flag has been mentioned only three times on the list.
Once, when it was added in 2009:
https://lore.kernel.org/git/cover.1234102794.git.marius@trolltech.com/
In 2013, when somebody fixed some compilation errors in the conditional
code (presumably because they used it while making other changes):
https://lore.kernel.org/git/1373871253-96480-1-git-send-email-sunshine@sunshineco.com/
And finally it seemed to have been useful to somebody in 2020:
https://lore.kernel.org/git/87eejswql6.fsf@evledraar.gmail.com/
So it's not totally without value. On the other hand, it's not likely to
be useful to non-developers (and certainly isn't if you have to
recompile). And using a debugger or adding your own inspection code is
likely to be as useful. So I've just dropped the code entirely here.
Note that we do still have to mark a few parameters unused in callback
functions which are passed to string_list_clear_func(). Those get an
extra pointer with the string being cleared, which we previously fed to
the debugging code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-18 03:16:26 +08:00
|
|
|
if (mi->name == NULL && mi->email == NULL)
|
2009-02-08 22:34:29 +08:00
|
|
|
return 0;
|
2013-01-06 05:26:40 +08:00
|
|
|
if (mi->email) {
|
|
|
|
*email = mi->email;
|
|
|
|
*emaillen = strlen(*email);
|
|
|
|
}
|
|
|
|
if (mi->name) {
|
|
|
|
*name = mi->name;
|
|
|
|
*namelen = strlen(*name);
|
|
|
|
}
|
2007-04-27 15:41:15 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|