aboutsummaryrefslogtreecommitdiffstats
path: root/mailmap.c
AgeCommit message (Collapse)AuthorFilesLines
2023-06-21object-store-ll.h: split this header out of object-store.hElijah Newren1-1/+1
The vast majority of files including object-store.h did not need dir.h nor khash.h. Split the header into two files, and let most just depend upon object-store-ll.h, while letting the two callers that need it depend on the full object-store.h. After this patch: $ git grep -h include..object-store | sort | uniq -c 2 #include "object-store.h" 129 #include "object-store-ll.h" Diff best viewed with `--color-moved`. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-25Merge branch 'en/header-split-cache-h'Junio C Hamano1-1/+2
Header clean-up. * en/header-split-cache-h: (24 commits) protocol.h: move definition of DEFAULT_GIT_PORT from cache.h mailmap, quote: move declarations of global vars to correct unit treewide: reduce includes of cache.h in other headers treewide: remove double forward declaration of read_in_full cache.h: remove unnecessary includes treewide: remove cache.h inclusion due to pager.h changes pager.h: move declarations for pager.c functions from cache.h treewide: remove cache.h inclusion due to editor.h changes editor: move editor-related functions and declarations into common file treewide: remove cache.h inclusion due to object.h changes object.h: move some inline functions and defines from cache.h treewide: remove cache.h inclusion due to object-file.h changes object-file.h: move declarations for object-file.c functions from cache.h treewide: remove cache.h inclusion due to git-zlib changes git-zlib: move declarations for git-zlib functions from cache.h treewide: remove cache.h inclusion due to object-name.h changes object-name.h: move declarations for object-name.c functions from cache.h treewide: remove unnecessary cache.h inclusion treewide: be explicit about dependence on mem-pool.h treewide: be explicit about dependence on oid-array.h ...
2023-04-11treewide: remove cache.h inclusion due to object-name.h changesElijah Newren1-1/+1
Signed-off-by: Elijah Newren <newren@gmail.com> Acked-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-11object-name.h: move declarations for object-name.c functions from cache.hElijah Newren1-0/+1
Signed-off-by: Elijah Newren <newren@gmail.com> Acked-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-06Merge branch 'en/header-split-cleanup'Junio C Hamano1-0/+2
Split key function and data structure definitions out of cache.h to new header files and adjust the users. * en/header-split-cleanup: csum-file.h: remove unnecessary inclusion of cache.h write-or-die.h: move declarations for write-or-die.c functions from cache.h treewide: remove cache.h inclusion due to setup.h changes setup.h: move declarations for setup.c functions from cache.h treewide: remove cache.h inclusion due to environment.h changes environment.h: move declarations for environment.c functions from cache.h treewide: remove unnecessary includes of cache.h wrapper.h: move declarations for wrapper.c functions from cache.h path.h: move function declarations for path.c functions from cache.h cache.h: remove expand_user_path() abspath.h: move absolute path functions from cache.h environment: move comment_line_char from cache.h treewide: remove unnecessary cache.h inclusion from several sources treewide: remove unnecessary inclusion of gettext.h treewide: be explicit about dependence on gettext.h treewide: remove unnecessary cache.h inclusion from a few headers
2023-04-06Merge branch 'ab/remove-implicit-use-of-the-repository'Junio C Hamano1-2/+2
Code clean-up around the use of the_repository. * ab/remove-implicit-use-of-the-repository: libs: use "struct repository *" argument, not "the_repository" post-cocci: adjust comments for recent repo_* migration cocci: apply the "revision.h" part of "the_repository.pending" cocci: apply the "rerere.h" part of "the_repository.pending" cocci: apply the "refs.h" part of "the_repository.pending" cocci: apply the "promisor-remote.h" part of "the_repository.pending" cocci: apply the "packfile.h" part of "the_repository.pending" cocci: apply the "pretty.h" part of "the_repository.pending" cocci: apply the "object-store.h" part of "the_repository.pending" cocci: apply the "diff.h" part of "the_repository.pending" cocci: apply the "commit.h" part of "the_repository.pending" cocci: apply the "commit-reach.h" part of "the_repository.pending" cocci: apply the "cache.h" part of "the_repository.pending" cocci: add missing "the_repository" macros to "pending" cocci: sort "the_repository" rules by header cocci: fix incorrect & verbose "the_repository" rules cocci: remove dead rule from "the_repository.pending.cocci"
2023-04-04Merge branch 'ab/remove-implicit-use-of-the-repository' into ↵Junio C Hamano1-2/+2
en/header-split-cache-h * ab/remove-implicit-use-of-the-repository: libs: use "struct repository *" argument, not "the_repository" post-cocci: adjust comments for recent repo_* migration cocci: apply the "revision.h" part of "the_repository.pending" cocci: apply the "rerere.h" part of "the_repository.pending" cocci: apply the "refs.h" part of "the_repository.pending" cocci: apply the "promisor-remote.h" part of "the_repository.pending" cocci: apply the "packfile.h" part of "the_repository.pending" cocci: apply the "pretty.h" part of "the_repository.pending" cocci: apply the "object-store.h" part of "the_repository.pending" cocci: apply the "diff.h" part of "the_repository.pending" cocci: apply the "commit.h" part of "the_repository.pending" cocci: apply the "commit-reach.h" part of "the_repository.pending" cocci: apply the "cache.h" part of "the_repository.pending" cocci: add missing "the_repository" macros to "pending" cocci: sort "the_repository" rules by header cocci: fix incorrect & verbose "the_repository" rules cocci: remove dead rule from "the_repository.pending.cocci"
2023-03-28cocci: apply the "object-store.h" part of "the_repository.pending"Ævar Arnfjörð Bjarmason1-1/+1
Apply the part of "the_repository.pending.cocci" pertaining to "object-store.h". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28cocci: apply the "cache.h" part of "the_repository.pending"Ævar Arnfjörð Bjarmason1-1/+1
Apply the part of "the_repository.pending.cocci" pertaining to "cache.h". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-21setup.h: move declarations for setup.c functions from cache.hElijah Newren1-0/+1
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-21environment.h: move declarations for environment.c functions from cache.hElijah Newren1-0/+1
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-17mailmap: drop debugging codeJeff King1-39/+3
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>
2022-05-20Merge branch 'ep/maint-equals-null-cocci'Junio C Hamano1-7/+7
Introduce and apply coccinelle rule to discourage an explicit comparison between a pointer and NULL, and applies the clean-up to the maintenance track. * ep/maint-equals-null-cocci: tree-wide: apply equals-null.cocci tree-wide: apply equals-null.cocci contrib/coccinnelle: add equals-null.cocci
2022-05-02tree-wide: apply equals-null.cocciJunio C Hamano1-7/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-07string-list API: change "nr" and "alloc" to "size_t"Ævar Arnfjörð Bjarmason1-3/+4
Change the "nr" and "alloc" members of "struct string_list" to use "size_t" instead of "nr". On some platforms the size of an "unsigned int" will be smaller than a "size_t", e.g. a 32 bit unsigned v.s. 64 bit unsigned. As "struct string_list" is a generic API we use in a lot of places this might cause overflows. As one example: code in "refs.c" keeps track of the number of refs with a "size_t", and auxiliary code in builtin/remote.c in get_ref_states() appends those to a "struct string_list". While we're at it split the "nr" and "alloc" in string-list.h across two lines, which is the case for most such struct member declarations (e.g. in "strbuf.h" and "strvec.h"). Changing e.g. "int i" to "size_t i" in run_and_feed_hook() isn't strictly necessary, and there are a lot more cases where we'll use a local "int", "unsigned int" etc. variable derived from the "nr" in the "struct string_list". But in that case as well as add_wrapped_shortlog_msg() in builtin/shortlog.c we need to adjust the printf format referring to "nr" anyway, so let's also change the other variables referring to it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10Merge branch 'ab/mailmap-leakfix'Junio C Hamano1-0/+2
Leakfix. * ab/mailmap-leakfix: mailmap.c: fix a memory leak in free_mailap_{info,entry}()
2021-08-31mailmap.c: fix a memory leak in free_mailap_{info,entry}()Ævar Arnfjörð Bjarmason1-0/+2
In the free_mailmap_entry() code added in 0925ce4d49 (Add map_user() and clear_mailmap() to mailmap, 2009-02-08) the intent was clearly to clear the "me" structure, but while we freed parts of the mailmap_entry structure, we didn't free the structure itself. The same goes for the "mailmap_info" structure. This brings the number of SANITIZE=leak failures in t4203-mailmap.sh down from 50 to 49. Not really progress as far as the number of failures is concerned, but as far as I can tell this fixes all leaks in mailmap.c itself. There's still users of it such as builtin/log.c that call read_mailmap() without a clear_mailmap(), but that's on them. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-13*.c static functions: add missing __attribute__((format))Ævar Arnfjörð Bjarmason1-0/+1
Add missing __attribute__((format)) function attributes to various "static" functions that take printf arguments. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-22Merge branch 'jk/open-dotgitx-with-nofollow'Junio C Hamano1-5/+17
It does not make sense to make ".gitattributes", ".gitignore" and ".mailmap" symlinks, as they are supposed to be usable from the object store (think: bare repositories where HEAD:.mailmap etc. are used). When these files are symbolic links, we used to read the contents of the files pointed by them by mistake, which has been corrected. * jk/open-dotgitx-with-nofollow: mailmap: do not respect symlinks for in-tree .mailmap exclude: do not respect symlinks for in-tree .gitignore attr: do not respect symlinks for in-tree .gitattributes exclude: add flags parameter to add_patterns() attr: convert "macro_ok" into a flags field add open_nofollow() helper
2021-03-13use CALLOC_ARRAYRené Scharfe1-1/+1
Add and apply a semantic patch for converting code that open-codes CALLOC_ARRAY to use it instead. It shortens the code and infers the element size automatically. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-16mailmap: do not respect symlinks for in-tree .mailmapJeff King1-5/+17
As with .gitattributes and .gitignore, we would like to make sure that .mailmap files are handled consistently whether read from the a blob (as is the default behavior in a bare repo) or from the filesystem. Likewise, we would like to avoid reading out-of-tree files pointed to by a symlink, which could have security implications in certain setups. We can cover both by using open_nofollow() when opening the in-tree files. We'll continue to follow links for mailmap.file, as well as when reading .mailmap from the current directory when outside of a repository entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-10mailmap: only look for .mailmap in work treeJeff King1-1/+2
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-01-12shortlog: remove unused(?) "repo-abbrev" featureÆvar Arnfjörð Bjarmason1-35/+13
Remove support for the magical "repo-abbrev" comment in .mailmap files. This was added to .mailmap parsing in [1], as a generalized feature of the git-shortlog Perl script added earlier in [2]. There was no documentation or tests for this feature, and I don't think it's used in practice anymore. What it did was to allow you to specify a single string to be search-replaced with "/.../" in the .mailmap file. E.g. for linux.git's current .mailmap: git archive --remote=git@gitlab.com:linux-kernel/linux.git \ HEAD -- .mailmap | grep -a repo-abbrev # repo-abbrev: /pub/scm/linux/kernel/git/ Then when running e.g.: git shortlog --merges --author=Linus -1 v5.10-rc7..v5.10 | grep Merge We'd emit (the [...] is mine): Merge tag [...]git://git.kernel.org/.../tip/tip But will now emit: Merge tag [...]git.kernel.org/pub/scm/linux/kernel/git/tip/tip I think at this point this is just a historical artifact we can get rid of. It was initially meant for Linus's own use when we integrated the Perl script[2], but since then it seems he's stopped using it. Digging through Linus's release announcements on the LKML[3] the last release I can find that made use of this output is Linux 2.6.25-rc6 back in March 2008[4]. Later on Linus started using --no-merges[5], and nowadays seems to prefer some custom not-quite-shortlog format of merges from lieutenants[6]. You will still see it on linux.git if you run "git shortlog" manually yourself with --merges, with this removed you can still get the same output with: git log --pretty=fuller v5.10-rc7..v5.10 | sed 's!/pub/scm/linux/kernel/git/!/.../!g' | git shortlog Arguably we should do the same for the search-replacing of "[PATCH]" at the beginning with "". That seems to be another relic of a bygone era when linux.git patches would have their E-Mail subject lines applied as-is by "git am" or whatever. But we documented that feature in "git-shortlog(1)", and it seems more widely applicable than something purely kernel-specific. 1. 7595e2ee6ef (git-shortlog: make common repository prefix configurable with .mailmap, 2006-11-25) 2. fa375c7f1b6 (Add git-shortlog perl script, 2005-06-04) 3. https://lore.kernel.org/lkml/ 4. https://lore.kernel.org/lkml/alpine.LFD.1.00.0803161651350.3020@woody.linux-foundation.org/ 5. https://lore.kernel.org/lkml/BANLkTinrbh7Xi27an3uY7pDWrNKhJRYmEA@mail.gmail.com/ 6. https://lore.kernel.org/lkml/CAHk-=wg1+kf1AVzXA-RQX0zjM6t9J2Kay9xyuNqcFHWV-y5ZYw@mail.gmail.com/ Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-16object-store: move object access functions to object-store.hStefan Beller1-0/+1
This should make these functions easier to find and cache.h less overwhelming to read. In particular, this moves: - read_object_file - oid_object_info - write_object_file As a result, most of the codebase needs to #include object-store.h. In this patch the #include is only added to files that would fail to compile otherwise. It would be better to #include wherever identifiers from the header are used. That can happen later when we have better tooling for it. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14sha1_file: convert read_sha1_file to struct object_idbrian m. carlson1-1/+1
Convert read_sha1_file to take a pointer to struct object_id and rename it read_object_file. Do the same for read_sha1_file_extended. Convert one use in grep.c to use the new function without any other code change, since the pointer being passed is a void pointer that is already initialized with a pointer to struct object_id. Update the declaration and definitions of the modified functions, and apply the following semantic patch to convert the remaining callers: @@ expression E1, E2, E3; @@ - read_sha1_file(E1.hash, E2, E3) + read_object_file(&E1, E2, E3) @@ expression E1, E2, E3; @@ - read_sha1_file(E1->hash, E2, E3) + read_object_file(E1, E2, E3) @@ expression E1, E2, E3, E4; @@ - read_sha1_file_extended(E1.hash, E2, E3, E4) + read_object_file_extended(&E1, E2, E3, E4) @@ expression E1, E2, E3, E4; @@ - read_sha1_file_extended(E1->hash, E2, E3, E4) + read_object_file_extended(E1, E2, E3, E4) Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17Convert remaining callers of get_sha1 to get_oid.brian m. carlson1-3/+3
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-12cocci: refactor common patterns to use xstrdup_or_null()Junio C Hamano1-4/+2
d64ea0f83b ("git-compat-util: add xstrdup_or_null helper", 2015-01-12) added a handy wrapper that allows us to get a duplicate of a string or NULL if the original is NULL, but a handful of codepath predate its introduction or just weren't aware of it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-17Merge branch 'nd/error-errno'Junio C Hamano1-2/+1
The code for warning_errno/die_errno has been refactored and a new error_errno() reporting helper is introduced. * nd/error-errno: (41 commits) wrapper.c: use warning_errno() vcs-svn: use error_errno() upload-pack.c: use error_errno() unpack-trees.c: use error_errno() transport-helper.c: use error_errno() sha1_file.c: use {error,die,warning}_errno() server-info.c: use error_errno() sequencer.c: use error_errno() run-command.c: use error_errno() rerere.c: use error_errno() and warning_errno() reachable.c: use error_errno() mailmap.c: use error_errno() ident.c: use warning_errno() http.c: use error_errno() and warning_errno() grep.c: use error_errno() gpg-interface.c: use error_errno() fast-import.c: use error_errno() entry.c: use error_errno() editor.c: use error_errno() diff-no-index.c: use error_errno() ...
2016-05-09mailmap.c: use error_errno()Nguyễn Thái Ngọc Duy1-2/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-06mailmap: do not resolve blobs in a non-repositoryJeff King1-1/+2
The mailmap code may be triggered outside of a repository by git-shortlog. There is no point in looking up a name like "HEAD:.mailmap" there; without a repository, we have no refs. This is unlikely to matter much in practice for the current code, as we would simply fail to find the ref. But as the refs code learns about new backends, this is more important; without a repository, we do not even know which backend to look at. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25mailmap: replace strcpy with xstrdupJeff King1-2/+1
We want to make a copy of a string without any leading whitespace. To do so, we allocate a buffer large enough to hold the original, skip past the whitespace, then copy that. It's much simpler to just allocate after we've skipped, in which case we can just copy the remainder of the string, leaving no question of whether "len" is large enough. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-04mailmap: use higher level string list functionsStefan Beller1-13/+7
No functional changes intended. This commit makes use of higher level and better documented functions of the string list API, so the code is more understandable. Note that also the required computational amount should not change in principal as we need to look up the item no matter if it is already part of the list or not. Once looked up, insertion comes for free. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-24Merge branch 'jc/strcasecmp-pure-inline'Jonathan Nieder1-2/+16
* jc/strcasecmp-pure-inline: mailmap: work around implementations with pure inline strcasecmp
2013-09-12mailmap: work around implementations with pure inline strcasecmpJunio C Hamano1-2/+16
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. Work it around by introducing our own level of indirection. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-11Merge branch 'sb/mailmap-freeing-NULL-is-ok'Junio C Hamano1-2/+1
* sb/mailmap-freeing-NULL-is-ok: mailmap: remove redundant check for freeing memory
2013-09-09Merge branch 'jk/mailmap-incomplete-line'Junio C Hamano1-12/+9
* jk/mailmap-incomplete-line: mailmap: handle mailmap blobs without trailing newlines
2013-08-28mailmap: handle mailmap blobs without trailing newlinesJeff King1-12/+9
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-20mailmap: remove redundant check for freeing memoryStefan Beller1-2/+1
The condition as it is written in that line has already been checked in the beginning of the function, which was introduced in 8503ee4 (2007-05-01, Fix read_mailmap to handle a caller uninterested in repo abbreviation) Helped-by: Jeff King <peff@peff.net> Helped-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15mailmap: style fixesJunio C Hamano1-15/+27
Wrap overlong lines and format the multi-line comments to match our coding style. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15mailmap: debug: avoid passing NULL to fprintf() '%s' conversion specificationEric Sunshine1-6/+9
POSIX does not state the behavior of '%s' conversion when passed a NULL pointer. Some implementations interpolate literal "(null)"; others may crash. Callers of debug_mm() often pass NULL as indication of either a missing name or email address. Instead, let's always supply a proper string pointer, and make it a bit more descriptive: "(none)" Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15mailmap: debug: eliminate -Wformat field precision type warningEric Sunshine1-3/+3
The compiler complains that '*' in fprintf() format "%.*s" should have type int, but we pass size_t. Fix this. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15mailmap: debug: fix malformed fprintf() format conversion specificationEric Sunshine1-1/+1
Resolve segmentation fault due to size_t variable being consumed by '%s'. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15mailmap: debug: fix out-of-order fprintf() argumentsEric Sunshine1-1/+1
Resolve segmentation fault due to arguments passed in wrong order. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15mailmap: do not downcase mailmap entriesJunio C Hamano1-12/+8
The email addresses in the records read from the .mailmap file are downcased very early, and then used to match against e-mail addresses in the input. Because we do use case insensitive version of string list to manage these entries, there is no need to do this, and worse yet, downcasing the rewritten/canonical e-mail read from the .mailmap file loses information. Stop doing that, and also make the string list used to keep multiple names for an mailmap entry case insensitive (the code that uses the list, lookup_prefix(), expects a case insensitive match). Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15mailmap: do not lose single-letter namesJunio C Hamano1-1/+1
In parse_name_and_email() function, there is this line: *name = (nstart < nend ? nstart : NULL); When the function is given a buffer "A <A@example.org> <old@x.z>", nstart scans from the beginning of the buffer, skipping whitespaces (there isn't any, so nstart points at the buffer), while nend starts from one byte before the first '<' and skips whitespaces backwards and stops at the first non-whitespace (i.e. it hits "A" at the beginning of the buffer). nstart == nend in this case for a single-letter name, and an off-by-one error makes it fail to pick up the name, which makes the entry equivalent to <A@example.org> <old@x.z> without the name. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-20Merge branch 'ap/log-mailmap'Junio C Hamano1-36/+72
Teach commands in the "log" family to optionally pay attention to the mailmap. * ap/log-mailmap: log --use-mailmap: optimize for cases without --author/--committer search log: add log.mailmap configuration option log: grep author/committer using mailmap test: add test for --use-mailmap option log: add --use-mailmap option pretty: use mailmap to display username and email mailmap: add mailmap structure to rev_info and pp mailmap: simplify map_user() interface mailmap: remove email copy and length limitation Use split_ident_line to parse author and committer string-list: allow case-insensitive string list
2013-01-10mailmap: simplify map_user() interfaceAntoine Pelisse1-25/+18
Simplify map_user(), mostly to avoid copies of string buffers. It also simplifies caller functions. map_user() directly receive pointers and length from the commit buffer as mail and name. If mapping of the user and mail can be done, the pointer is updated to a new location. Lengths are also updated if necessary. The caller of map_user() can then copy the new email and name if necessary. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-10mailmap: remove email copy and length limitationJunio C Hamano1-16/+59
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>
2012-12-13mailmap: default mailmap.blob in bare repositoriesJeff King1-0/+5
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-12mailmap: clean up read_mailmap error handlingJeff King1-11/+21
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-12mailmap: support reading mailmap from blobsJeff King1-2/+47
In a bare repository, there isn't a simple way to respect an in-tree mailmap without extracting it to a temporary file. This patch provides a config variable, similar to mailmap.file, which reads the mailmap from a blob in the repository. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12mailmap: refactor mailmap parsing for non-file sourcesJeff King1-34/+40
The read_single_mailmap function opens a mailmap file and parses each line. In preparation for having non-file mailmaps, let's pull out the line-parsing logic into its own function (read_mailmap_line), and rename the file-parsing function to match (read_mailmap_file). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-28mailmap: avoid out-of-bounds memory accessRomain Francoise1-1/+1
AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html) complains of a one-byte buffer underflow in parse_name_and_email() while running the test suite. And indeed, if one of the lines in the mailmap begins with '<', we dereference the address just before the beginning of the buffer when looking for whitespace to remove, before checking that we aren't going too far. So reverse the order of the tests to make sure that we don't read outside the buffer. Signed-off-by: Romain Francoise <romain@orebokech.com> Signed-off-by: Jeff King <peff@peff.net>
2012-02-06mailmap: always return a plain mail address from map_user()Junio C Hamano1-8/+10
The callers of map_user() give email and name to it, and expect to get the up-to-date email and/or name to be used in their output. The function rewrites the given buffers in place. To optimize the majority of cases, the function returns 0 when it did not do anything, and it returns 1 when the caller should use the updated contents. The 'email' input to the function is terminated by '>' or a NUL (whichever comes first) for historical reasons, but when a rewrite happens, the value is replaced with the mailbox inside the <> pair. However, it failed to meet this expectation when it only rewrote the name part without rewriting the email part, and the email in the input was terminated by '>'. This causes an extra '>' to appear in the output of "blame -e", because the caller does send in '>'-terminated email, and when the function returned 1 to tell it that rewriting happened, it appends '>' that is necessary when the email part was rewritten. The patch looks bigger than it actually is, because this change makes a variable that points at the end of the email part in the input 'p' live much longer than it used to, deserving a more descriptive name. Noticed and diagnosed by Felipe Contreras and Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13Merge branch 'ml/mailmap' into maint-1.7.6Junio C Hamano1-3/+2
* ml/mailmap: mailmap: xcalloc mailmap_info Conflicts: mailmap.c
2011-11-16mailmap: xcalloc mailmap_infoMarc-André Lureau1-3/+2
This is to avoid reaching free of uninitialized members. With an invalid .mailmap (and perhaps in other cases), it can reach free(mi->name) with garbage for example. Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13mailmap: fix use of freed memoryJim Meyering1-4/+6
On an x86_64 system (F13-based), I ran these commands in an empty directory: git init printf '%s\n' \ '<jdoe@example.com> <jdoe@example.COM>' \ 'John <jdoe@example.com>' > .mailmap git shortlog < /dev/null Here's the result: (reading log message from standard input) *** glibc detected *** git: free(): invalid pointer: 0x0000000000f53730 *** ======= Backtrace: ========= /lib64/libc.so.6[0x31ba875676] git[0x48c2a5] git[0x4b9858] ... zsh: abort (core dumped) git shortlog What happened? Some .mailmap entry is of the <email1> <email2> form, while a subsequent one looks like "User Name <Email2>, and the two email addresses on the right are not identical but are "equal" when using a case-insensitive comparator. Then, when add_mapping is processing the latter line, new_email is NULL and we free me->email, yet do not replace it with a new strdup'd string. Thus, when later we attempt to use the buffer behind that ->email pointer, we reference freed memory. The solution is to free ->email and ->name only if we're about to replace them. [jc: squashed in the tests from Jonathan] Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for string_list_lookupJulian Phillips1-2/+2
Update the definition and callers of string_list_lookup to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for string_list_insert_at_indexJulian Phillips1-1/+1
Update the definition and callers of string_list_insert_at_index to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27string_list: Fix argument order for string_list_insertJulian Phillips1-1/+1
Update the definition and callers of string_list_insert to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12mailmap.c: remove unused functionJunio C Hamano1-5/+0
map_email() is not used anywhere. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-20Fix various sparse warnings in the git source codeLinus Torvalds1-3/+3
There are a few remaining ones, but this fixes the trivial ones. It boils down to two main issues that sparse complains about: - warning: Using plain integer as NULL pointer Sparse doesn't like you using '0' instead of 'NULL'. For various good reasons, not the least of which is just the visual confusion. A NULL pointer is not an integer, and that whole "0 works as NULL" is a historical accident and not very pretty. A few of these remain: zlib is a total mess, and Z_NULL is just a 0. I didn't touch those. - warning: symbol 'xyz' was not declared. Should it be static? Sparse wants to see declarations for any functions you export. A lack of a declaration tends to mean that you should either add one, or you should mark the function 'static' to show that it's in file scope. A few of these remain: I only did the ones that should obviously just be made static. That 'wt_status_submodule_summary' one is debatable. It has a few related flags (like 'wt_status_use_color') which _are_ declared, and are used by builtin-commit.c. So maybe we'd like to export it at some point, but it's not declared now, and not used outside of that file, so 'static' it is in this patch. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-01Merge branch 'maint'Junio C Hamano1-0/+9
* maint: Documentation: Remove an odd "instead" fix portability problem with IS_RUN_COMMAND_ERR mailmap: resurrect lower-casing of email addresses
2009-04-01Mailmap: Allow empty email addresses to be mappedBjörn Steinbrink1-4/+5
While it makes no sense to map some email address to an empty one, doing things the other way around can be useful. For example when using filter-branch with an env-filter that employs a mailmap to fix up an import that created such broken commits with empty email addresses. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-01mailmap: resurrect lower-casing of email addressesJohannes Schindelin1-0/+9
Commit 0925ce4(Add map_user() and clear_mailmap() to mailmap) broke the lower-casing of email addresses. This mostly did not matter if your .mailmap has only lower-case email addresses; However, we did not require .mailmap to contain lowercase-only email addresses. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-08Add map_user() and clear_mailmap() to mailmapMarius Storm-Olsen1-28/+168
map_user() allows to lookup and replace both email and name of a user, based on a new style mailmap file. The possible mailmap definitions are now: proper_name <commit_email> # Old style <proper_email> <commit_email> # New style proper_name <proper_email> <commit_email> # New style proper_name <proper_email> commit_name <commit_email> # New style map_email() operates the same as before, with the exception that it also will to try to match on a name passed in through the name return buffer. clear_mailmap() is needed to now clear the more complex mailmap structure. Signed-off-by: Marius Storm-Olsen <marius@trolltech.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-08Add mailmap.file as configurational option for mailmap locationMarius Storm-Olsen1-2/+10
This allows us to augment the repo mailmap file, and to use mailmap files elsewhere than the repository root. Meaning that the entries in mailmap.file will override the entries in "./.mailmap", should they match. Signed-off-by: Marius Storm-Olsen <marius@trolltech.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-21Rename path_list to string_listJohannes Schindelin1-6/+6
The name path_list was correct for the first usage of that data structure, but it really is a general-purpose string list. $ perl -i -pe 's/path-list/string-list/g' $(git grep -l path-list) $ perl -i -pe 's/path_list/string_list/g' $(git grep -l path_list) $ git mv path-list.h string-list.h $ git mv path-list.c string-list.c $ perl -i -pe 's/has_path/has_string/g' $(git grep -l has_path) $ perl -i -pe 's/path/string/g' string-list.[ch] $ git mv Documentation/technical/api-path-list.txt \ Documentation/technical/api-string-list.txt $ perl -i -pe 's/strdup_paths/strdup_strings/g' $(git grep -l strdup_paths) ... and then fix all users of string-list to access the member "string" instead of "path". Documentation/technical/api-string-list.txt needed some rewrapping, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-08mailmap: fix bogus for() loop that happened to be safe by accidentJunio C Hamano1-3/+4
The empty loop pretended to have an empty statement as its body by a phony indentation, but in fact was slurping the next statement into it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceJunio C Hamano1-1/+0
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-30Include mailmap.h in mailmap.c to catch mailmap interface changesAlex Riesen1-0/+1
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-30Fix read_mailmap to handle a caller uninterested in repo abbreviationAlex Riesen1-0/+3
The only such a caller builtin-blame.c would pass NULL as the place where to store the abbreviation. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-30Use strlcpy instead of strncpy in mailmap.cAlex Riesen1-1/+1
strncpy does not NUL-terminate output in case of output buffer too short, and map_email prototype (and usage) does not allow for figuring out what the length of the name is. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-29Split out mailmap handling out of shortlogJunio C Hamano1-0/+88
This splits out a few functions to deal with mailmap from shortlog and makes it a bit more usable from other programs. Most notably, it does not clobber input e-mail address anymore. Signed-off-by: Junio C Hamano <junkio@cox.net>