builtin/fsck.c: don't conflate "int" and "enum" in callback

Fix a warning on AIX's xlc compiler that's been emitted since my
a1aad71601a (fsck.h: use "enum object_type" instead of "int",
2021-03-28):

    "builtin/fsck.c", line 805.32: 1506-068 (W) Operation between
    types "int(*)(struct object*,enum object_type,void*,struct
    fsck_options*)" and "int(*)(struct object*,int,void*,struct
    fsck_options*)" is not allowed.

I.e. it complains about us assigning a function with a prototype "int"
where we're expecting "enum object_type".

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: use new fsck API to printing dangling submodules

Refactor the check added in 5476e1efde (fetch-pack: print and use
dangling .gitmodules, 2021-02-22) to make use of us now passing the
"msg_id" to the user defined "error_func". We can now compare against
the FSCK_MSG_GITMODULES_MISSING instead of parsing the generated
message.

Let's also replace register_found_gitmodules() with directly
manipulating the "gitmodules_found" member. A recent commit moved it
into "fsck_options" so we could do this here.

I'm sticking this callback in fsck.c. Perhaps in the future we'd like
to accumulate such callbacks into another file (maybe fsck-cb.c,
similar to parse-options-cb.c?), but while we've got just the one
let's just put it into fsck.c.

A better alternative in this case would be some library some more
obvious library shared by fetch-pack.c ad builtin/index-pack.c, but
there isn't such a thing.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: use file-scope static struct for fsck_options

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>

fetch-pack: don't needlessly copy fsck_options

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>

fsck.c: move gitmodules_{found,done} into fsck_options

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>

fsck.c: add an fsck_set_msg_type() API that takes enums

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>

fsck.c: pass along the fsck_msg_id in the fsck_error callback

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>

fsck.[ch]: move FOREACH_FSCK_MSG_ID & fsck_msg_id from *.c to *.h

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>

fsck.c: give "FOREACH_MSG_ID" a more specific name

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>

fsck.c: undefine temporary STR macro after use

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>

fsck.c: call parse_msg_type() early in fsck_set_msg_type()

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>

fsck.h: re-order and re-assign "enum fsck_msg_type"

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>

fsck.h: move FSCK_{FATAL,INFO,ERROR,WARN,IGNORE} into an enum

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>

fsck.c: refactor fsck_msg_type() to limit scope of "int msg_type"

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>

fsck.c: rename remaining fsck_msg_id "id" to "msg_id"

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>

fsck.c: remove (mostly) redundant append_msg_id() function

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>

fsck.c: rename variables in fsck_set_msg_type() for less confusion

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>

fsck.h: use "enum object_type" instead of "int"

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>

fsck.h: use designed initializers for FSCK_OPTIONS_{DEFAULT,STRICT}

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>

fsck.c: refactor and rename common config callback

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>

Git 2.31

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jn/mergetool-hideresolved-is-optional'

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

Merge branch 'tb/pack-revindex-on-disk'

Fix for a topic in 'master'.

* tb/pack-revindex-on-disk:
  pack-revindex.c: don't close unopened file descriptors

Merge tag 'l10n-2.31.0-rnd2' of git://github.com/git-l10n/git-po

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

l10n: zh_CN: for git v2.31.0 l10n round 1 and 2

Translate 161 new messages (5104t0f0u) for git 2.31.0.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge branch 'master' of github.com:vnwildman/git

* 'master' of github.com:vnwildman/git:
  l10n: vi.po(5104t): for git v2.31.0 l10n round 2

Merge branch 'l10n/zh_TW/210301' of github.com:l10n-tw/git-po

* 'l10n/zh_TW/210301' of github.com:l10n-tw/git-po:
  l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated)

Merge branch 'po-id' of github.com:bagasme/git-po

* 'po-id' of github.com:bagasme/git-po:
  l10n: Add translation team info
  l10n: start Indonesian translation

Merge branch 'master' of github.com:Softcatala/git-po

* 'master' of github.com:Softcatala/git-po:
  l10n: Update Catalan translation

Merge branch 'russian-l10n' of github.com:DJm00n/git-po-ru

* 'russian-l10n' of github.com:DJm00n/git-po-ru:
  l10n: ru.po: update Russian translation

Merge branch 'pt-PT' of github.com:git-l10n-pt-PT/git-po

* 'pt-PT' of github.com:git-l10n-pt-PT/git-po:
  l10n: pt_PT: add Portuguese translations part 1

doc: describe mergetool configuration in git-mergetool(1)

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>

mergetool: do not enable hideResolved by default

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>

Git 2.31-rc2

Sync with Git 2.30.2 for CVE-2021-21300

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jt/transfer-fsck-across-packs-fix'

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

l10n: de.po: Update German translation for Git v2.31.0

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>

l10n: pt_PT: add Portuguese translations part 1

* Newlines corrected.
* Add concept translation table.
* Translated some.
* Corrected some.
* Corrected some 'Negation of Emptiness'.

Signed-off-by: Daniel Santos <hello@brighterdan.com>

l10n: vi.po(5104t): for git v2.31.0 l10n round 2

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

l10n: es: 2.31.0 round 2

Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com>

l10n: Add translation team info

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>

l10n: start Indonesian translation

  * 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>

fetch-pack: do not mix --pack_header and packfile uri

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>

l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated)

Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>

l10n: bg.po: Updated Bulgarian translation (5104t)

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

Merge branch 'fr_next' of github.com:jnavila/git

* 'fr_next' of github.com:jnavila/git:
  l10n: fr: v2.31 rnd 2

Merge branch 'master' of github.com:nafmo/git-l10n-sv

* 'master' of github.com:nafmo/git-l10n-sv:
  l10n: sv.po: Update Swedish translation (5104t0f0u)

Merged the open-eintr workaround for macOS

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/RelNotes: improve release note for rename detection work

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>

Merge branch 'jk/open-returns-eintr'

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

l10n: fr: v2.31 rnd 2

Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>

Merge https://github.com/prati0100/git-gui

* https://github.com/prati0100/git-gui:
  Revert "git-gui: remove lines starting with the comment character"

l10n: tr: v2.31.0-rc1

Signed-off-by: Emir Sarı <bitigchi@me.com>

l10n: sv.po: Update Swedish translation (5104t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

l10n: git.pot: v2.31.0 round 2 (9 new, 8 removed)

Generate po/git.pot from v2.31.0-rc1 for git v2.31.0 l10n round 2.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge branch 'master' of github.com:git/git

* 'master' of github.com:git/git: (63 commits)
  Git 2.31-rc1
  Hopefully the last batch before -rc1
  Revert "commit-graph: when incompatible with graphs, indicate why"
  read-cache: make the index write buffer size 128K
  dir: fix malloc of root untracked_cache_dir
  commit-graph.c: display correct number of chunks when writing
  doc/reftable: document how to handle windows
  fetch-pack: print and use dangling .gitmodules
  fetch-pack: with packfile URIs, use index-pack arg
  http-fetch: allow custom index-pack args
  http: allow custom index-pack args
  chunk-format: add technical docs
  chunk-format: restore duplicate chunk checks
  midx: use 64-bit multiplication for chunk sizes
  midx: use chunk-format read API
  commit-graph: use chunk-format read API
  chunk-format: create read chunk API
  midx: use chunk-format API in write_midx_internal()
  midx: drop chunk progress during write
  midx: return success/failure in chunk write methods
  ...

Merge branch 'py/revert-commit-comments'

This commit causes breakage on macOS, or in fact any platform using
older versions of Tcl. Revert it.

* py/revert-commit-comments:
  Revert "git-gui: remove lines starting with the comment character"

Revert "git-gui: remove lines starting with the comment character"

This reverts commit b9a43869c9f96d3577d6f568c1bda1940c8f0e31.

This commit causes breakage on macOS (10.13). It causes errors on
startup and completely breaks the commit functionality. There are two
main problems. First, it uses `string cat` which is not supported on
older Tcl versions. Second, it does a half close of the bidirectional
pipe to git-stripspace which is also not supported on older Tcl
versions.

Reported-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

Git 2.31-rc1

Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: tr: v2.31.0-rc0

Signed-off-by: Emir Sarı <bitigchi@me.com>

Hopefully the last batch before -rc1

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jh/untracked-cache-fix'

An under-allocation for the untracked cache data has been corrected.

* jh/untracked-cache-fix:
  dir: fix malloc of root untracked_cache_dir

Merge branch 'ns/raise-write-index-buffer-size'

Raise the buffer size used when writing the index file out from
(obviously too small) 8kB to (clearly sufficiently large) 128kB.

* ns/raise-write-index-buffer-size:
  read-cache: make the index write buffer size 128K

Merge branch 'hv/trailer-formatting'

The logic to handle "trailer" related placeholders in the
"--format=" mechanisms in the "log" family and "for-each-ref"
family is getting unified.

* hv/trailer-formatting:
  ref-filter: use pretty.c logic for trailers
  pretty.c: capture invalid trailer argument
  pretty.c: refactor trailer logic to `format_set_trailers_options()`
  t6300: use function to test trailer options

Merge branch 'hn/reftable-tables-doc-update'

Documentation update.

* hn/reftable-tables-doc-update:
  doc/reftable: document how to handle windows

Merge branch 'sv/t7001-modernize'

Test script modernization.

* sv/t7001-modernize:
  t7001: use `test` rather than `[`
  t7001: use here-docs instead of echo
  t7001: put each command on a separate line
  t7001: use '>' rather than 'touch'
  t7001: avoid using `cd` outside of subshells
  t7001: remove whitespace after redirect operators
  t7001: modernize subshell formatting
  t7001: remove unnecessary blank lines
  t7001: indent with TABs instead of spaces
  t7001: modernize test formatting

Merge branch 'jt/transfer-fsck-across-packs'

The approach to "fsck" the incoming objects in "index-pack" is
attractive for performance reasons (we have them already in core,
inflated and ready to be inspected), but fundamentally cannot be
applied fully when we receive more than one pack stream, as a tree
object in one pack may refer to a blob object in another pack as
".gitmodules", when we want to inspect blobs that are used as
".gitmodules" file, for example.  Teach "index-pack" to emit
objects that must be inspected later and check them in the calling
"fetch-pack" process.

* jt/transfer-fsck-across-packs:
  fetch-pack: print and use dangling .gitmodules
  fetch-pack: with packfile URIs, use index-pack arg
  http-fetch: allow custom index-pack args
  http: allow custom index-pack args

Merge branch 'ds/chunked-file-api'

The common code to deal with "chunked file format" that is shared
by the multi-pack-index and commit-graph files have been factored
out, to help codepaths for both filetypes to become more robust.

* ds/chunked-file-api:
  commit-graph.c: display correct number of chunks when writing
  chunk-format: add technical docs
  chunk-format: restore duplicate chunk checks
  midx: use 64-bit multiplication for chunk sizes
  midx: use chunk-format read API
  commit-graph: use chunk-format read API
  chunk-format: create read chunk API
  midx: use chunk-format API in write_midx_internal()
  midx: drop chunk progress during write
  midx: return success/failure in chunk write methods
  midx: add num_large_offsets to write_midx_context
  midx: add pack_perm to write_midx_context
  midx: add entries to write_midx_context
  midx: use context in write_midx_pack_names()
  midx: rename pack_info to write_midx_context
  commit-graph: use chunk-format write API
  chunk-format: create chunk format write API
  commit-graph: anonymize data in chunk_write_fn

Merge branch 'en/diffcore-rename'

Performance optimization work on the rename detection continues.

* en/diffcore-rename:
  merge-ort: call diffcore_rename() directly
  gitdiffcore doc: mention new preliminary step for rename detection
  diffcore-rename: guide inexact rename detection based on basenames
  diffcore-rename: complete find_basename_matches()
  diffcore-rename: compute basenames of source and dest candidates
  t4001: add a test comparing basename similarity and content similarity
  diffcore-rename: filter rename_src list when possible
  diffcore-rename: no point trying to find a match better than exact

Merge branch 'jh/fsmonitor-prework'

Preliminary changes to fsmonitor integration.

* jh/fsmonitor-prework:
  fsmonitor: refactor initialization of fsmonitor_last_update token
  fsmonitor: allow all entries for a folder to be invalidated
  fsmonitor: log FSMN token when reading and writing the index
  fsmonitor: log invocation of FSMonitor hook to trace2
  read-cache: log the number of scanned files to trace2
  read-cache: log the number of lstat calls to trace2
  preload-index: log the number of lstat calls to trace2
  p7519: add trace logging during perf test
  p7519: move watchman cleanup earlier in the test
  p7519: fix watchman watch-list test on Windows
  p7519: do not rely on "xargs -d" in test

Merge https://github.com/prati0100/git-gui

* https://github.com/prati0100/git-gui:
  git-gui: remove lines starting with the comment character
  git-gui: fix typo in russian locale

Merge branch 'js/commit-graph-warning'

* js/commit-graph-warning:
  Revert "commit-graph: when incompatible with graphs, indicate why"

Revert "commit-graph: when incompatible with graphs, indicate why"

This reverts commit c85eec7fc37e1ca79072f263ae6ea1ee305ba38c, as
it is a bit overzealous, we are in prerelease freeze, and we want
to have enough time to get this right and cook in 'next'.

cf. <8735xgkvuo.fsf@evledraar.gmail.com>

config.mak.uname: enable OPEN_RETURNS_EINTR for macOS Big Sur

We've had mixed reports on whether the latest release of macOS needs
this Makefile knob set. In most reported cases, there's antivirus
software running (which one might imagine could cause an open() call to
be delayed). However, one of the (off-list) reports I've gotten
indicated that it happened on an otherwise clean install of Big Sur.

Since the symptom is so bad (checkout randomly fails to write several
fails when the progress meter kicks in), and since the workaround is so
lightweight (if we don't see EINTR, it's just an extra conditional
check), let's just turn it on by default.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of github.com:nafmo/git-l10n-sv

* 'master' of github.com:nafmo/git-l10n-sv:
  l10n: sv.po: Update Swedish translation (5103t0f0u)

Merge branch 'pl' of github.com:Arusekk/git-po

* 'pl' of github.com:Arusekk/git-po:
  l10n: pl.po: Update translation

l10n: sv.po: Update Swedish translation (5103t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

l10n: pl.po: Update translation

Signed-off-by: Arusekk <arek_koz@o2.pl>

l10n: fr: v2.31.0 rnd 1

Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>

pack-revindex.c: don't close unopened file descriptors

When opening a reverse index, load_revindex_from_disk() jumps to the
'cleanup' label in case something goes wrong: the reverse index had the
wrong size, an unrecognized version, or similar.

It also jumps to this label when the reverse index couldn't be opened in
the first place, which will cause an error with the unguarded close()
call in the label.

Guard this call with "if (fd >= 0)" to make sure that we have a valid
file descriptor to close before attempting to close it.

Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: add OPEN_RETURNS_EINTR knob

On some platforms, open() reportedly returns EINTR when opening regular
files and we receive a signal (usually SIGALRM from our progress meter).
This shouldn't happen, as open() should be a restartable syscall, and we
specify SA_RESTART when setting up the alarm handler. So it may actually
be a kernel or libc bug for this to happen. But it has been reported on
at least one version of Linux (on a network filesystem):

  https://lore.kernel.org/git/c8061cce-71e4-17bd-a56a-a5fed93804da@neanderfunk.de/

as well as on macOS starting with Big Sur even on a regular filesystem.

We can work around it by retrying open() calls that get EINTR, just as
we do for read(), etc. Since we don't ever _want_ to interrupt an open()
call, we can get away with just redefining open, rather than insisting
all callsites use xopen().

We actually do have an xopen() wrapper already (and it even does this
retry, though there's no indication of it being an observed problem back
then; it seems simply to have been lifted from xread(), etc). But it is
used hardly anywhere, and isn't suitable for general use because it will
die() on error. In theory we could combine the two, but it's awkward to
do so because of the variable-args interface of open().

This patch adds a Makefile knob for enabling the workaround. It's not
enabled by default for any platforms in config.mak.uname yet, as we
don't have enough data to decide how common this is (I have not been
able to reproduce on either Linux or Big Sur myself). It may be worth
enabling preemptively anyway, since the cost is pretty low (if we don't
see an EINTR, it's just an extra conditional).

However, note that we must not enable this on Windows. It doesn't do
anything there, and the macro overrides the existing mingw_open()
redirection. I've added a preemptive #undef here in the mingw header
(which is processed first) to just quietly disable it (we could also
make it an #error, but there is little point in being so aggressive).

Reported-by: Aleksey Kliger <alklig@microsoft.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: git.pot: v2.31.0 round 1 (155 new, 89 removed)

Generate po/git.pot from v2.31.0-rc0 for git v2.31.0 l10n round 1.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Git 2.31-rc0

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/push-delete-nothing'

"git push $there --delete ''" should have been diagnosed as an
error, but instead turned into a matching push, which has been
corrected.

* jc/push-delete-nothing:
  push: do not turn --delete '' into a matching push

Merge branch 'sh/mergetools-vimdiff1'

Mergetools update.

* sh/mergetools-vimdiff1:
  mergetools/vimdiff: add vimdiff1 merge tool variant

Merge branch 'dl/doc-config-camelcase'

A handful of multi-word configuration variable names in
documentation that are spelled in all lowercase have been corrected
to use the more canonical camelCase.

* dl/doc-config-camelcase:
  index-format doc: camelCase core.excludesFile
  blame-options.txt: camelcase blame.blankBoundary
  i18n.txt: camel case and monospace "i18n.commitEncoding"

Merge branch 'js/params-vs-args'

Messages update.

* js/params-vs-args:
  replace "parameters" by "arguments" in error messages

Merge branch 'ug/doc-commit-approxidate'

Doc update.

* ug/doc-commit-approxidate:
  doc: mention approxidates for git-commit --date

Merge branch 'es/maintenance-of-bare-repositories'

The "git maintenance register" command had trouble registering bare
repositories, which had been corrected.

* es/maintenance-of-bare-repositories:
  maintenance: fix incorrect `maintenance.repo` path with bare repository

Merge branch 'mt/add-chmod-fixes'

Various fixes on "git add --chmod".

* mt/add-chmod-fixes:
  add: propagate --chmod errors to exit status
  add: mark --chmod error string for translation
  add --chmod: don't update index when --dry-run is used

Merge branch 'ds/merge-base-independent'

The code to implement "git merge-base --independent" was poorly
done and was kept from the very beginning of the feature.

* ds/merge-base-independent:
  commit-reach: stale commits may prune generation further
  commit-reach: use heuristic in remove_redundant()
  commit-reach: move compare_commits_by_gen
  commit-reach: use one walk in remove_redundant()
  commit-reach: reduce requirements for remove_redundant()

Merge branch 'ah/rebase-no-fork-point-config'

"git rebase --[no-]fork-point" gained a configuration variable
rebase.forkPoint so that users do not have to keep specifying a
non-default setting.

* ah/rebase-no-fork-point-config:
  rebase: add a config option for --no-fork-point

Merge branch 'mt/grep-sparse-checkout'

"git grep" has been tweaked to be limited to the sparse checkout
paths.

* mt/grep-sparse-checkout:
  grep: honor sparse-checkout on working tree searches

Merge branch 'ah/commit-graph-leakplug'

Plug a minor memory leak.

* ah/commit-graph-leakplug:
  commit-graph: avoid leaking topo_levels slab in write_commit_graph()

Merge branch 'zh/difftool-skip-to'

"git difftool" learned "--skip-to=<path>" option to restart an
interrupted session from an arbitrary path.

* zh/difftool-skip-to:
  difftool.c: learn a new way start at specified file

Merge branch 'cw/pack-config-doc'

Doc update.

* cw/pack-config-doc:
  doc: mention bigFileThreshold for packing

Merge branch 'jc/maint-column-doc-typofix'

Doc update.

* jc/maint-column-doc-typofix:
  Documentation: typofix --column description

Merge branch 'ma/doc-markup-fix'

Docfix.

* ma/doc-markup-fix:
  gitmailmap.txt: fix rendering of e-mail addresses
  git.txt: fix monospace rendering
  rev-list-options.txt: fix rendering of bonus paragraph

Merge branch 'jc/diffcore-rotate'

"git {diff,log} --{skip,rotate}-to=<path>" allows the user to
discard diff output for early paths or move them to the end of the
output.

* jc/diffcore-rotate:
  diff: --{rotate,skip}-to=<path>

Merge branch 'mt/checkout-index-corner-cases'

The error codepath around the "--temp/--prefix" feature of "git
checkout-index" has been improved.

* mt/checkout-index-corner-cases:
  checkout-index: omit entries with no tempname from --temp output
  write_entry(): fix misuses of `path` in error messages