summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-03-28fetch-pack: use file-scope static struct for fsck_optionsLibravatar Ævar Arnfjörð Bjarmason1-3/+3
Change code added in 5476e1efde (fetch-pack: print and use dangling .gitmodules, 2021-02-22) so that we use a file-scoped "static struct fsck_options" instead of defining one in the "fsck_gitmodules_oids()" function. We use this pattern in all of builtin/{fsck,index-pack,mktag,unpack-objects}.c. It's odd to see fetch-pack be the odd one out. One might think that we're using other fsck_options structs in fetch-pack, or doing on fsck twice there, but we're not. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fetch-pack: don't needlessly copy fsck_optionsLibravatar Ævar Arnfjörð Bjarmason1-7/+3
Change the behavior of the .gitmodules validation added in 5476e1efde (fetch-pack: print and use dangling .gitmodules, 2021-02-22) so we're using one "fsck_options". I found that code confusing to read. One might think that not setting up the error_func earlier means that we're relying on the "error_func" not being set in some code in between the two hunks being modified here. But we're not, all we're doing in the rest of "cmd_index_pack()" is further setup by calling fsck_set_msg_types(), and assigning to do_fsck_object. So there was no reason in 5476e1efde to make a shallow copy of the fsck_options struct before setting error_func. Let's just do this setup at the top of the function, along with the "walk" assignment. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: move gitmodules_{found,done} into fsck_optionsLibravatar Ævar Arnfjörð Bjarmason3-15/+19
Move the gitmodules_{found,done} static variables added in 159e7b080bf (fsck: detect gitmodules files, 2018-05-02) into the fsck_options struct. It makes sense to keep all the context in the same place. This requires changing the recently added register_found_gitmodules() function added in 5476e1efde (fetch-pack: print and use dangling .gitmodules, 2021-02-22) to take fsck_options. That function will be removed in a subsequent commit, but as it'll require the new gitmodules_found attribute of "fsck_options" we need this intermediate step first. An earlier version of this patch removed the small amount of duplication we now have between FSCK_OPTIONS_{DEFAULT,STRICT} with a FSCK_OPTIONS_COMMON macro. I don't think such de-duplication is worth it for this amount of copy/pasting. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: add an fsck_set_msg_type() API that takes enumsLibravatar Ævar Arnfjörð Bjarmason3-11/+22
Change code I added in acf9de4c94e (mktag: use fsck instead of custom verify_tag(), 2021-01-05) to make use of a new API function that takes the fsck_msg_{id,type} types, instead of arbitrary strings that we'll (hopefully) parse into those types. At the time that the fsck_set_msg_type() API was introduced in 0282f4dced0 (fsck: offer a function to demote fsck errors to warnings, 2015-06-22) it was only intended to be used to parse user-supplied data. For things that are purely internal to the C code it makes sense to have the compiler check these arguments, and to skip the sanity checking of the data in fsck_set_msg_type() which is redundant to checks we get from the compiler. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: pass along the fsck_msg_id in the fsck_error callbackLibravatar Ævar Arnfjörð Bjarmason5-6/+14
Change the fsck_error callback to also pass along the fsck_msg_id. Before this change the only way to get the message id was to parse it back out of the "message". Let's pass it down explicitly for the benefit of callers that might want to use it, as discussed in [1]. Passing the msg_type is now redundant, as you can always get it back from the msg_id, but I'm not changing that convention. It's really common to need the msg_type, and the report() function itself (which calls "fsck_error") needs to call fsck_msg_type() to discover it. Let's not needlessly re-do that work in the user callback. 1. https://lore.kernel.org/git/87blcja2ha.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.[ch]: move FOREACH_FSCK_MSG_ID & fsck_msg_id from *.c to *.hLibravatar Ævar Arnfjörð Bjarmason2-66/+66
Move the FOREACH_FSCK_MSG_ID macro and the fsck_msg_id enum it helps define from fsck.c to fsck.h. This is in preparation for having non-static functions take the fsck_msg_id as an argument. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: give "FOREACH_MSG_ID" a more specific nameLibravatar Ævar Arnfjörð Bjarmason1-3/+3
Rename the FOREACH_MSG_ID macro to FOREACH_FSCK_MSG_ID in preparation for moving it over to fsck.h. It's good convention to name macros in *.h files in such a way as to clearly not clash with any other names in other files. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: undefine temporary STR macro after useLibravatar Ævar Arnfjörð Bjarmason1-0/+1
In f417eed8cde (fsck: provide a function to parse fsck message IDs, 2015-06-22) the "STR" macro was introduced, but that short macro name was not undefined after use as was done earlier in the same series for the MSG_ID macro in c99ba492f1c (fsck: introduce identifiers for fsck messages, 2015-06-22). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: call parse_msg_type() early in fsck_set_msg_type()Libravatar Ævar Arnfjörð Bjarmason1-2/+1
There's no reason to defer the calling of parse_msg_type() until after we've checked if the "id < 0". This is not a hot codepath, and parse_msg_type() itself may die on invalid input. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.h: re-order and re-assign "enum fsck_msg_type"Libravatar Ævar Arnfjörð Bjarmason1-4/+6
Change the values in the "enum fsck_msg_type" from being manually assigned to using default C enum values. This means we end up with a FSCK_IGNORE=0, which was previously defined as "2". I'm confident that nothing relies on these values, we always compare them for equality. Let's not omit "0" so it won't be assumed that we're using these as a boolean somewhere. This also allows us to re-structure the fields to mark which are "private" v.s. "public". See the preceding commit for a rationale for not simply splitting these into two enums, namely that this is used for both the private and public fsck API. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.h: move FSCK_{FATAL,INFO,ERROR,WARN,IGNORE} into an enumLibravatar Ævar Arnfjörð Bjarmason5-20/+25
Move the FSCK_{FATAL,INFO,ERROR,WARN,IGNORE} defines into a new fsck_msg_type enum. These defines were originally introduced in: - ba002f3b28a (builtin-fsck: move common object checking code to fsck.c, 2008-02-25) - f50c4407305 (fsck: disallow demoting grave fsck errors to warnings, 2015-06-22) - efaba7cc77f (fsck: optionally ignore specific fsck issues completely, 2015-06-22) - f27d05b1704 (fsck: allow upgrading fsck warnings to errors, 2015-06-22) The reason these were defined in two different places is because we use FSCK_{IGNORE,INFO,FATAL} only in fsck.c, but FSCK_{ERROR,WARN} are used by external callbacks. Untangling that would take some more work, since we expose the new "enum fsck_msg_type" to both. Similar to "enum object_type" it's not worth structuring the API in such a way that only those who need FSCK_{ERROR,WARN} pass around a different type. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: refactor fsck_msg_type() to limit scope of "int msg_type"Libravatar Ævar Arnfjörð Bjarmason1-7/+5
Refactor "if options->msg_type" and other code added in 0282f4dced0 (fsck: offer a function to demote fsck errors to warnings, 2015-06-22) to reduce the scope of the "int msg_type" variable. This is in preparation for changing its type in a subsequent commit, only using it in the "!options->msg_type" scope makes that change This also brings the code in line with the fsck_set_msg_type() function (also added in 0282f4dced0), which does a similar check for "!options->msg_type". Another minor benefit is getting rid of the style violation of not having braces for the body of the "if". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: rename remaining fsck_msg_id "id" to "msg_id"Libravatar Ævar Arnfjörð Bjarmason1-3/+3
Rename the remaining variables of type fsck_msg_id from "id" to "msg_id". This change is relatively small, and is worth the churn for a later change where we have different id's in the "report" function. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: remove (mostly) redundant append_msg_id() functionLibravatar Ævar Arnfjörð Bjarmason1-19/+2
Remove the append_msg_id() function in favor of calling prepare_msg_ids(). We already have code to compute the camel-cased msg_id strings in msg_id_info, let's use it. When the append_msg_id() function was added in 71ab8fa840f (fsck: report the ID of the error/warning, 2015-06-22) the prepare_msg_ids() function didn't exist. When prepare_msg_ids() was added in a46baac61eb (fsck: factor out msg_id_info[] lazy initialization code, 2018-05-26) this code wasn't moved over to lazy initialization. This changes the behavior of the code to initialize all the messages instead of just camel-casing the one we need on the fly. Since the common case is that we're printing just one message this is mostly redundant work. But that's OK in this case, reporting this fsck issue to the user isn't performance-sensitive. If we were somehow doing so in a tight loop (in a hopelessly broken repository?) this would help, since we'd save ourselves from re-doing this work for identical messages, we could just grab the prepared string from msg_id_info after the first invocation. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.c: rename variables in fsck_set_msg_type() for less confusionLibravatar Ævar Arnfjörð Bjarmason2-13/+13
Rename variables in a function added in 0282f4dced0 (fsck: offer a function to demote fsck errors to warnings, 2015-06-22). It was needlessly confusing that it took a "msg_type" argument, but then later declared another "msg_type" of a different type. Let's rename that to "severity", and rename "id" to "msg_id" and "msg_id" to "msg_id_str" etc. This will make a follow-up change smaller. While I'm at it properly indent the fsck_set_msg_type() argument list. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.h: use "enum object_type" instead of "int"Libravatar Ævar Arnfjörð Bjarmason4-4/+8
Change the fsck_walk_func to use an "enum object_type" instead of an "int" type. The types are compatible, and ever since this was added in 355885d5315 (add generic, type aware object chain walker, 2008-02-25) we've used entries from object_type (OBJ_BLOB etc.). So this doesn't really change anything as far as the generated code is concerned, it just gives the compiler more information and makes this easier to read. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-28fsck.h: use designed initializers for FSCK_OPTIONS_{DEFAULT,STRICT}Libravatar Ævar Arnfjörð Bjarmason1-2/+8
Refactor the definitions of FSCK_OPTIONS_{DEFAULT,STRICT} to use designated initializers. This allows us to omit those fields that are initialized to 0 or NULL. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-17fsck.c: refactor and rename common config callbackLibravatar Ævar Arnfjörð Bjarmason4-16/+5
Refactor code I recently changed in 1f3299fda9 (fsck: make fsck_config() re-usable, 2021-01-05) so that I could use fsck's config callback in mktag in 1f3299fda9 (fsck: make fsck_config() re-usable, 2021-01-05). I don't know what I was thinking in structuring the code this way, but it clearly makes no sense to have an fsck_config_internal() at all just so it can get a fsck_options when git_config() already supports passing along some void* data. Let's just make use of that instead, which gets us rid of the two wrapper functions, and brings fsck's common config callback in line with other such reusable config callbacks. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-15Git 2.31Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-14Merge branch 'jn/mergetool-hideresolved-is-optional'Libravatar Junio C Hamano3-8/+7
Disable the recent mergetool's hideresolved feature by default for backward compatibility and safety. * jn/mergetool-hideresolved-is-optional: doc: describe mergetool configuration in git-mergetool(1) mergetool: do not enable hideResolved by default
2021-03-14Merge branch 'tb/pack-revindex-on-disk'Libravatar Junio C Hamano1-1/+2
Fix for a topic in 'master'. * tb/pack-revindex-on-disk: pack-revindex.c: don't close unopened file descriptors
2021-03-14Merge tag 'l10n-2.31.0-rnd2' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano16-43702/+75702
l10n for Git 2.31.0 round 2 * tag 'l10n-2.31.0-rnd2' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.31.0 l10n round 1 and 2 l10n: de.po: Update German translation for Git v2.31.0 l10n: pt_PT: add Portuguese translations part 1 l10n: vi.po(5104t): for git v2.31.0 l10n round 2 l10n: es: 2.31.0 round 2 l10n: Add translation team info l10n: start Indonesian translation l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated) l10n: bg.po: Updated Bulgarian translation (5104t) l10n: fr: v2.31 rnd 2 l10n: tr: v2.31.0-rc1 l10n: sv.po: Update Swedish translation (5104t0f0u) l10n: git.pot: v2.31.0 round 2 (9 new, 8 removed) l10n: tr: v2.31.0-rc0 l10n: sv.po: Update Swedish translation (5103t0f0u) l10n: pl.po: Update translation l10n: fr: v2.31.0 rnd 1 l10n: git.pot: v2.31.0 round 1 (155 new, 89 removed) l10n: Update Catalan translation l10n: ru.po: update Russian translation
2021-03-15l10n: zh_CN: for git v2.31.0 l10n round 1 and 2Libravatar Jiang Xin1-2985/+3337
Translate 161 new messages (5104t0f0u) for git 2.31.0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-03-15Merge branch 'master' of github.com:vnwildman/gitLibravatar Jiang Xin1-3051/+3508
* 'master' of github.com:vnwildman/git: l10n: vi.po(5104t): for git v2.31.0 l10n round 2
2021-03-14Merge branch 'l10n/zh_TW/210301' of github.com:l10n-tw/git-poLibravatar Jiang Xin1-3072/+3535
* 'l10n/zh_TW/210301' of github.com:l10n-tw/git-po: l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated)
2021-03-14Merge branch 'po-id' of github.com:bagasme/git-poLibravatar Jiang Xin2-0/+24362
* 'po-id' of github.com:bagasme/git-po: l10n: Add translation team info l10n: start Indonesian translation
2021-03-14Merge branch 'master' of github.com:Softcatala/git-poLibravatar Jiang Xin1-13/+12
* 'master' of github.com:Softcatala/git-po: l10n: Update Catalan translation
2021-03-14Merge branch 'russian-l10n' of github.com:DJm00n/git-po-ruLibravatar Jiang Xin1-5661/+7873
* 'russian-l10n' of github.com:DJm00n/git-po-ru: l10n: ru.po: update Russian translation
2021-03-14Merge branch 'pt-PT' of github.com:git-l10n-pt-PT/git-poLibravatar Jiang Xin1-2902/+3226
* 'pt-PT' of github.com:git-l10n-pt-PT/git-po: l10n: pt_PT: add Portuguese translations part 1
2021-03-13doc: describe mergetool configuration in git-mergetool(1)Libravatar Jonathan Nieder1-0/+4
In particular, this describes mergetool.hideResolved, which can help users discover this setting (either because it may be useful to them or in order to understand mergetool's behavior if they have forgotten setting it in the past). Tested by running make -C Documentation git-mergetool.1 man Documentation/git-mergetool.1 and reading through the page. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-13mergetool: do not enable hideResolved by defaultLibravatar Jonathan Nieder2-8/+3
When 98ea309b3f (mergetool: add hideResolved configuration, 2021-02-09) introduced the mergetool.hideResolved setting to reduce the clutter in viewing non-conflicted sections of files in a mergetool, it enabled it by default, explaining: No adverse effects were noted in a small survey of popular mergetools[1] so this behavior defaults to `true`. In practice, alas, adverse effects do appear. A few issues: 1. No indication is shown in the UI that the base, local, and remote versions shown have been modified by additional resolution. This is inherent in the design: the idea of mergetool.hideResolved is to convince a mergetool that expects pristine local, base, and remote files to show partially resolved verisons of those files instead; there is no additional source of information accessible to the mergetool to see where the resolution has happened. (By contrast, a mergetool generating the partial resolution from conflict markers for itself would be able to hilight the resolved sections with a different color.) A user accustomed to seeing the files without partial resolution gets no indication that this behavior has changed when they upgrade Git. 2. If the computed merge did not line up the files correctly (for example due to repeated sections in the file), the partially resolved files can be misleading and do not have enough information to reconstruct what happened and compute the correct merge result. 3. Resolving a conflict can involve information beyond the textual conflict. For example, if the local and remote versions added overlapping functionality in different ways, seeing the full unresolved versions of each alongside the base gives information about each side's intent that makes it possible to come up with a resolution that combines those two intents. By contrast, when starting with partially resolved versions of those files, one can produce a subtly wrong resolution that includes redundant extra code added by one side that is not needed in the approach taken on the other. All that said, a user wanting to focus on textual conflicts with reduced clutter can still benefit from mergetool.hideResolved=true as a way to deemphasize sections of the code that resolve cleanly without requiring any changes to the invoked mergetool. The caveats described above are reduced when the user has explicitly turned this on, because then the user is aware of them. Flip the default to 'false'. Reported-by: Dana Dahlstrom <dahlstrom@google.com> Helped-by: Seth House <seth@eseth.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-08Git 2.31-rc2Libravatar Junio C Hamano2-1/+3
2021-03-08Sync with Git 2.30.2 for CVE-2021-21300Libravatar Junio C Hamano23-4/+292
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-08Merge branch 'jt/transfer-fsck-across-packs-fix'Libravatar Junio C Hamano2-2/+23
The code to fsck objects received across multiple packs during a single git fetch session has been broken when the packfile URI feature was in use. A workaround has been added by disabling the codepath to avoid keeping a packfile that is too small. * jt/transfer-fsck-across-packs-fix: fetch-pack: do not mix --pack_header and packfile uri
2021-03-08l10n: de.po: Update German translation for Git v2.31.0Libravatar Matthias Rüster1-3208/+3565
Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
2021-03-08l10n: pt_PT: add Portuguese translations part 1Libravatar Daniel Santos1-2902/+3226
* Newlines corrected. * Add concept translation table. * Translated some. * Corrected some. * Corrected some 'Negation of Emptiness'. Signed-off-by: Daniel Santos <hello@brighterdan.com>
2021-03-08l10n: vi.po(5104t): for git v2.31.0 l10n round 2Libravatar Tran Ngoc Quan1-3051/+3508
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2021-03-07l10n: es: 2.31.0 round 2Libravatar Christopher Diaz Riveros1-4822/+5924
Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com>
2021-03-07l10n: Add translation team infoLibravatar Bagas Sanjaya1-0/+4
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
2021-03-07l10n: start Indonesian translationLibravatar Bagas Sanjaya1-0/+24358
* Initialize PO file * Translate init-db.c * Translate wt-status.c * Translate builtin/clone.c * Translate builtin/checkout.c * Translate builtin/fetch.c * Complete core translations: * builtin/remote.c * builtin/index-pack.c * push.c * reset.c * Sync with l10n upstream Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
2021-03-05fetch-pack: do not mix --pack_header and packfile uriLibravatar Jonathan Tan2-2/+23
When fetching (as opposed to cloning) from a repository with packfile URIs enabled, an error like this may occur: fatal: pack has bad object at offset 12: unknown object type 5 fatal: finish_http_pack_request gave result -1 fatal: fetch-pack: expected keep then TAB at start of http-fetch output This bug was introduced in b664e9ffa1 ("fetch-pack: with packfile URIs, use index-pack arg", 2021-02-22), when the index-pack args used when processing the inline packfile of a fetch response and when processing packfile URIs were unified. This bug happens because fetch, by default, partially reads (and consumes) the header of the inline packfile to determine if it should store the downloaded objects as a packfile or loose objects, and thus passes --pack_header=<...> to index-pack to inform it that some bytes are missing. However, when it subsequently fetches the additional packfiles linked by URIs, it reuses the same index-pack arguments, thus wrongly passing --index-pack-arg=--pack_header=<...> when no bytes are missing. This does not happen when cloning because "git clone" always passes do_keep, which instructs the fetch mechanism to always retain the packfile, eliminating the need to read the header. There are a few ways to fix this, including filtering out pack_header arguments when downloading the additional packfiles, but I decided to stick to always using index-pack throughout when packfile URIs are present - thus, Git no longer needs to read the bytes, and no longer needs --pack_header here. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-06l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated)Libravatar Yi-Jyun Pan1-3072/+3535
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
2021-03-05l10n: bg.po: Updated Bulgarian translation (5104t)Libravatar Alexander Shopov1-3060/+3440
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2021-03-05Merge branch 'fr_next' of github.com:jnavila/gitLibravatar Jiang Xin1-332/+411
* 'fr_next' of github.com:jnavila/git: l10n: fr: v2.31 rnd 2
2021-03-05Merge branch 'master' of github.com:nafmo/git-l10n-svLibravatar Jiang Xin1-297/+324
* 'master' of github.com:nafmo/git-l10n-sv: l10n: sv.po: Update Swedish translation (5104t0f0u)
2021-03-04Merged the open-eintr workaround for macOSLibravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-04Documentation/RelNotes: improve release note for rename detection workLibravatar Elijah Newren1-1/+1
There were some early changes in the 2.31 cycle to optimize some setup in diffcore-rename.c[1], some later changes to measure performance[2], and finally some significant changes to improve rename detection performance. The final one was merged with the note Performance optimization work on the rename detection continues. That works for the commit log, but feels misleading as a release note since all the changes were within one cycle. Simplify this to just Performance improvements for rename detection. The former wording could be seen as hinting that more performance improvements will come in 2.32, which is true, but we can just cover those in the 2.32 release notes when the time comes. [1] a5ac31b5b1 (Merge branch 'en/diffcore-rename', 2021-01-25) [2] d3a035b055 (Merge branch 'en/merge-ort-perf', 2021-02-11) [3] 12bd17521c (Merge branch 'en/diffcore-rename', 2021-03-01) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-04Merge branch 'jk/open-returns-eintr'Libravatar Junio C Hamano5-0/+42
Work around platforms whose open() is reported to return EINTR (it shouldn't, as we do our signals with SA_RESTART). * jk/open-returns-eintr: config.mak.uname: enable OPEN_RETURNS_EINTR for macOS Big Sur Makefile: add OPEN_RETURNS_EINTR knob
2021-03-04l10n: fr: v2.31 rnd 2Libravatar Jean-Noël Avila1-332/+411
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2021-03-04Merge https://github.com/prati0100/git-guiLibravatar Junio C Hamano2-21/+2
* https://github.com/prati0100/git-gui: Revert "git-gui: remove lines starting with the comment character"