git/mailmap.c, branch v2.35.2

Merge branch 'ab/mailmap-leakfix'

2021-09-10T18:46:28Z

Leakfix. * ab/mailmap-leakfix: mailmap.c: fix a memory leak in free_mailap_{info,entry}()

mailmap.c: fix a memory leak in free_mailap_{info,entry}()

2021-08-31T19:38:09Z

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 Signed-off-by: Junio C Hamano

*.c static functions: add missing attribute((format))

2021-07-13T22:20:20Z

Add missing __attribute__((format)) function attributes to various "static" functions that take printf arguments. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'jk/open-dotgitx-with-nofollow'

2021-03-22T21:00:22Z

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

use CALLOC_ARRAY

2021-03-14T00:00:09Z

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 Signed-off-by: Junio C Hamano

mailmap: do not respect symlinks for in-tree .mailmap

2021-02-16T17:41:33Z

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 Signed-off-by: Junio C Hamano

mailmap: only look for .mailmap in work tree

2021-02-10T21:34:51Z

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 Signed-off-by: Junio C Hamano

shortlog: remove unused(?) "repo-abbrev" feature

2021-01-12T22:04:42Z

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 Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

object-store: move object access functions to object-store.h

2018-05-16T02:42:03Z

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 Signed-off-by: Junio C Hamano

sha1_file: convert read_sha1_file to struct object_id

2018-03-14T16:23:50Z

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 Signed-off-by: Junio C Hamano