Let's reorder short usage help with the same
option list order as long usage help.

Signed-off-by: Miriam Rubio <mirucam@gmail.com>

`git bisect` shell has `view` as alternative to
`visualize` subcommand. Let's do the same with C command version.

Signed-off-by: Miriam Rubio <mirucam@gmail.com>

`git bisect--helper` command did not have `help` subcommand.
Let's add `help` subcommand with the same long usage message.

Signed-off-by: Miriam Rubio <mirucam@gmail.com>

As we want to rename the `git bisect--helper ...` command to `git bisect`,
let's replace all the `bisect--helper` strings related to
`git_bisect_helper_usage[]` with `bisect`.

In order to convert git bisect shell command to C, let's remove
git-bisect.sh, change cmd_bisect_helper() by cmd_bisect(),
rename builtin/bisect--helper.c to builtin/bisect.c and replace
names commands cmd_struct in git.c file..

Signed-off-by: Miriam Rubio <mirucam@gmail.com>

`git bisect` C command version calls `state` subcommand to mark good
or bad refs, but this subcommand is not needed in `git bisect`
Shell call. Let's hide this subcommand to the user.

Signed-off-by: Miriam Rubio <mirucam@gmail.com>

Rename bisect--helper.c command options to git-bisect.sh command options.

Signed-off-by: Miriam Rubio <mirucam@gmail.com>

"git branch -h" incorrectly said "--track[=direct|inherit]",
implying that "--trackinherit" is a valid option, which has been
corrected.

* js/branch-track-inherit:
  branch,checkout: fix --track usage strings

FreeBSD 13.0 headers have unconditional dependency on C11 language
features, and adding -std=gnu99 to DEVELOPER_CFLAGS would just
break the developer build.

* jc/freebsd-without-c99-only-build:
  Makefile: FreeBSD cannot do C99-or-below build

Josh Steadmon authored 3 years ago and Junio C Hamano committed 3 years ago

As Ævar pointed out in [1], the use of PARSE_OPT_LITERAL_ARGHELP with a
list of allowed parameters is not recommended. Both git-branch and
git-checkout were changed in d3115660 (branch: add flags and config to
inherit tracking, 2021-12-20) to use this discouraged combination for
their --track flags.

Fix this by removing PARSE_OPT_LITERAL_ARGHELP, and changing the arghelp
to simply be "mode". Users may discover allowed values in the manual
pages.

[1]: https://lore.kernel.org/git/220111.86a6g3yqf9.gmgdl@evledraar.gmail.com/



Signed-off-by: Josh Steadmon <steadmon@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

In "make DEVELOPER=YesPlease" builds, we try to help developers to
catch as many potential issues as they can by using -Wall and
turning compilation warnings into errors.  In the same spirit, we
recently started adding -std=gnu99 to their CFLAGS, so that they can
notice when they accidentally used language features beyond C99.

It however turns out that FreeBSD 13.0 mistakenly uses C11 extension
in its system header files regardless of what __STDC_VERSION__ says,
which means that the platform (unless we tweak their system headers)
cannot be used for this purpose.

It seems that -std=gnu99 is only added conditionally even in today's
config.mak.dev, so it is fine if we dropped -std=gnu99 from there.
Which means that developers on FreeBSD cannot participate in vetting
use of features beyond C99, but there are developers on other
platforms who will, so it's not too bad.

We might want a more "fundamental" fix to make the platform capable
of taking -std=gnu99, like working around the use of unconditional
C11 extension in its system header files by supplying a set of
"replacement" definitions in our header files.  We chose not to
pursue such an approach for two reasons at this point:

 (1) The fix belongs to the FreeBSD project, not this project, and
     such an upstream fix may happen hopefully in a not-too-distant
     future.

 (2) Fixing such a bug in system header files and working it around
     can lead to unexpected breakages (other parts of their system
     header files may not be expecting to see and do not work well
     with our "replacement" definitions).  This close to the final
     release of this cycle, we have no time for that.

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

Adjust build on RHEL 7 to explicitly ask C99 support and use
the fallback implementation of uncompress2 we ship.

* da/rhel7-lacks-uncompress2-and-c99:
  build: centos/RHEL 7 ships with an older gcc and zlib

davvid authored 3 years ago and Junio C Hamano committed 3 years ago

GCC 4.8.5 is the default system compiler on centos7/RHEL7.
This version requires -std=c99 to enable c99 support.

zlib 1.2.7 on centos7/rhel7 lacks uncompress2().

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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

Test fix.

* js/t1450-making-it-writable-does-not-need-full-posixperm:
  t1450-fsck: exec-bit is not needed to make loose object writable

A few portability tweaks.

* ab/reftable-build-fixes:
  reftable tests: avoid "int" overflow, use "uint64_t"
  reftable: avoid initializing structs from structs

A brown-paper-bag fix on top of a topic that was merged during this
cycle.

* ab/refs-errno-cleanup:
  refs API: use "failure_errno", not "errno"

Ævar Arnfjörð Bjarmason authored 3 years ago and Junio C Hamano committed 3 years ago

Change code added in 1ae2b8cd (reftable: add merged table view,
2021-10-07) to consistently use the "uint64_t" type. These "min" and
"max" variables get passed in the body of this function to a function
whose prototype is:

    [...] reftable_writer_set_limits([...], uint64_t min, uint64_t max

This avoids the following warning on SunCC 12.5 on
gcc211.fsffrance.org:

    "reftable/merged_test.c", line 27: warning: initializer does not fit or is out of range: 0xffffffff

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

Han-Wen Nienhuys authored 3 years ago and Junio C Hamano committed 3 years ago

Apparently, the IBM xlc compiler doesn't like this.

Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Johannes Sixt authored 3 years ago and Junio C Hamano committed 3 years ago

A test case wants to append stuff to a loose object file to ensure
that this kind of corruption is detected. To make a read-only loose
object file writable with chmod, it is not necessary to also make
it executable. Replace the bitmask 755 with the instruction +w to
request only the write bit and to also heed the umask. And get rid
of a POSIXPERM prerequisite, which is unnecessary for the test.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Ævar Arnfjörð Bjarmason authored 3 years ago and Junio C Hamano committed 3 years ago

Fix a logic error in refs_resolve_ref_unsafe() introduced in a recent
series of mine to abstract the refs API away from errno. See
96f6623a (Merge branch 'ab/refs-errno-cleanup', 2021-11-29)for that
series.

In that series introduction of "failure_errno" to
refs_resolve_ref_unsafe came in ef18119d (refs API: add a version
of refs_resolve_ref_unsafe() with "errno", 2021-10-16). There we'd set
"errno = 0" immediately before refs_read_raw_ref(), and then set
"failure_errno" to "errno" if errno was non-zero afterwards.

Then in the next commit 8b72fea7 (refs API: make
refs_read_raw_ref() not set errno, 2021-10-16) we started expecting
"refs_read_raw_ref()" to set "failure_errno". It would do that if
refs_read_raw_ref() failed, but it wouldn't be the same errno.

So we might set the "errno" here to any arbitrary bad value, and end
up e.g. returning NULL when we meant to return the refname from
refs_resolve_ref_unsafe(), or the other way around. Instrumenting this
code will reveal cases where refs_read_raw_ref() will fail, and
"errno" and "failure_errno" will be set to different values.

In practice I haven't found a case where this scary bug changed
anything in practice. The reason for that is that we'll not care about
the actual value of "errno" here per-se, but only whether:

 1. We have an errno
 2. If it's one of ENOENT, EISDIR or ENOTDIR. See the adjacent code
    added in a1c1d817 (refs_resolve_ref_unsafe: handle d/f
    conflicts for writes, 2017-10-06)

I.e. if we clobber "failure_errno" with "errno", but it happened to be
one of those three, and we'll clobber it with another one of the three
we were OK.

Perhaps there are cases where the difference ended up mattering, but I
haven't found them. Instrumenting the test suite to fail if "errno"
and "failure_errno" are different shows a lot of failures, checking if
they're different *and* one is but not the other is outside that list
of three "errno" values yields no failures.

But let's fix the obvious bug. We should just stop paying attention to
"errno" in refs_resolve_ref_unsafe(). In addition let's change the
partial resetting of "errno" in files_read_raw_ref() to happen just
before the "return", to ensure that any such bug will be more easily
spotted in the future.

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

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

Some lockfile code called free() in signal-death code path, which
has been corrected.

* ps/lockfile-cleanup-fix:
  fetch: fix deadlock when cleaning up lockfiles in async signals

Code clean-up.

* ma/header-dup-cleanup:
  cache.h: drop duplicate `ensure_full_index()` declaration

Test simplification.

* fs/gpg-unknown-key-test-fix:
  t/gpg: simplify test for unknown key

* ak/protect-any-current-branch:
  branch: missing space fix at line 313

* jt/pack-header-lshift-overflow:
  packfile: fix off-by-one error in decoding logic

* rb/nonstop-lacks-uncompress2:
  build: NonStop ships with an older zlib

Fix calling dynamically loaded functions on Windows.

* ma/windows-dynload-fix:
  lazyload: use correct calling conventions

"git merge $signed_tag" started to drop the tag message from the
default merge message it uses by accident, which has been corrected.

* fs/ssh-signing-key-lifetime:
  fmt-merge-msg: prevent use-after-free with signed tags

Randall Becker authored 3 years ago and Junio C Hamano committed 3 years ago

Notably, it lacks uncompress2(); use the fallback we ship in our
tree instead.

Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

shift count being exactly at 7-bit smaller than the long is OK; on
32-bit architecture, shift count starts at 4 and goes through 11, 18
and 25, at which point the guard triggers one iteration too early.

Reported-by: Marc Strapetz <marc.strapetz@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fabian Stelzer authored 3 years ago and Junio C Hamano committed 3 years ago

To test for a key that is completely unknown to the keyring we need one
to sign the commit with. This was done by generating a new key and not
add it into the keyring. To avoid the key generation overhead and
problems where GPG did hang in CI during it, switch GNUPGHOME to the
empty $GNUPGHOME_NOT_USED instead, therefore making all used keys unknown
for this single `verify-commit` call.

Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Fabian Stelzer <fs@gigacodes.de>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Bagas Sanjaya authored 3 years ago and Junio C Hamano committed 3 years ago

The message introduced by commit 593a2a5d (branch: protect branches
checked out in all worktrees, 2021-12-01) is missing a space in the
first line, add it.

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Taylor Blau authored 3 years ago and Junio C Hamano committed 3 years ago

When merging a signed tag, fmt_merge_msg_sigs() is responsible for
populating the body of the merge message with the names of the signed
tags, their signatures, and the validity of those signatures.

In 02769437 (ssh signing: use sigc struct to pass payload,
2021-12-09), check_signature() was taught to pass the object payload via
the sigc struct instead of passing the payload buffer separately.

In effect, 02769437 causes buf, and sigc.payload to point at the same
region in memory. This causes a problem for fmt_tag_signature(), which
wants to read from this location, since it is freed beforehand by
signature_check_clear() (which frees it via sigc's `payload` member).

That makes the subsequent use in fmt_tag_signature() a use-after-free.

As a result, merge messages did not contain the body of any signed tags.
Luckily, they tend not to contain garbage, either, since the result of
strstr()-ing the object buffer in fmt_tag_signature() is guarded:

    const char *tag_body = strstr(buf, "\n\n");
    if (tag_body) {
      tag_body += 2;
      strbuf_add(tagbuf, tag_body, buf + len - tag_body);
    }

Unfortunately, the tests in t6200 did not catch this at the time because
they do not search for the body of signed tags in fmt-merge-msg's
output.

Resolve this by waiting to call signature_check_clear() until after its
contents can be safely discarded. Harden ourselves against any future
regressions in this area by making sure we can find signed tag messages
in the output of fmt-merge-msg, too.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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

"git stash apply" forgot to attempt restoring untracked files when
it failed to restore changes to tracked ones.

* en/stash-df-fix:
  stash: do not return before restoring untracked files

Typofix.

* ms/t-readme-typofix:
  t/README: fix typo

Similar message templates have been consolidated so that
translators need to work on fewer number of messages.

* ja/i18n-similar-messages:
  i18n: turn even more messages into "cannot be used together" ones
  i18n: ref-filter: factorize "%(foo) atom used without %(bar) atom"
  i18n: factorize "--foo outside a repository"
  i18n: refactor "unrecognized %(foo) argument" strings
  i18n: factorize "no directory given for --foo"
  i18n: factorize "--foo requires --bar" and the like
  i18n: tag.c factorize i18n strings
  i18n: standardize "cannot open" and "cannot read"
  i18n: turn "options are incompatible" into "cannot be used together"
  i18n: refactor "%s, %s and %s are mutually exclusive"
  i18n: refactor "foo and bar are mutually exclusive"

A corner case bug in the ort merge strategy has been corrected.

* en/merge-ort-renorm-with-rename-delete-conflict-fix:
  merge-ort: fix bug with renormalization and rename/delete conflicts