git/git.git
18 months agoGit 2.23-rc2 v2.23.0-rc2
Junio C Hamano [Fri, 9 Aug 2019 17:15:39 +0000 (10:15 -0700)]
Git 2.23-rc2

Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agoMerge branch 'bc/hash-independent-tests-part-4'
Junio C Hamano [Fri, 9 Aug 2019 17:13:14 +0000 (10:13 -0700)]
Merge branch 'bc/hash-independent-tests-part-4'

Test fix.

* bc/hash-independent-tests-part-4:
  t0000: reword comments for "local" test
  t: decrease nesting in test_oid_to_path

18 months agoMerge branch 'rs/plug-strbuf-reak-in-read-alt-refs'
Junio C Hamano [Fri, 9 Aug 2019 17:13:14 +0000 (10:13 -0700)]
Merge branch 'rs/plug-strbuf-reak-in-read-alt-refs'

Leakfix.

* rs/plug-strbuf-reak-in-read-alt-refs:
  sha1-file: release strbuf after use

18 months agoMerge branch 'mt/dir-iterator-updates'
Junio C Hamano [Fri, 9 Aug 2019 17:13:14 +0000 (10:13 -0700)]
Merge branch 'mt/dir-iterator-updates'

Leakfix.

* mt/dir-iterator-updates:
  test-dir-iterator: use path argument directly
  dir-iterator: release strbuf after use

18 months agoMerge branch 'ds/commit-graph-incremental'
Junio C Hamano [Fri, 9 Aug 2019 17:13:13 +0000 (10:13 -0700)]
Merge branch 'ds/commit-graph-incremental'

Leakfix.

* ds/commit-graph-incremental:
  commit-graph: release strbufs after use

18 months agoMerge branch 'ja/l10n-fixes'
Junio C Hamano [Thu, 8 Aug 2019 21:26:10 +0000 (14:26 -0700)]
Merge branch 'ja/l10n-fixes'

A few messages have been updated to help localization better.

* ja/l10n-fixes:
  l10n: reformat some localized strings for v2.23.0

18 months agoMerge branch 'en/disable-dir-rename-in-recursive-merge'
Junio C Hamano [Thu, 8 Aug 2019 21:26:10 +0000 (14:26 -0700)]
Merge branch 'en/disable-dir-rename-in-recursive-merge'

"merge-recursive" hit a BUG() when building a virtual merge base
detected a directory rename.

* en/disable-dir-rename-in-recursive-merge:
  merge-recursive: avoid directory rename detection in recursive case

18 months agoMerge branch 'nd/switch-and-restore'
Junio C Hamano [Thu, 8 Aug 2019 21:26:09 +0000 (14:26 -0700)]
Merge branch 'nd/switch-and-restore'

Docfix.

* nd/switch-and-restore:
  restore: fix typo in docs

18 months agoMerge branch 'mr/doc-can-not-to-cannot'
Junio C Hamano [Thu, 8 Aug 2019 21:26:09 +0000 (14:26 -0700)]
Merge branch 'mr/doc-can-not-to-cannot'

Docfix.

* mr/doc-can-not-to-cannot:
  doc: typo: s/can not/cannot/ and s/is does/does/

18 months agoMerge branch 'ds/commit-graph-octopus-fix'
Junio C Hamano [Thu, 8 Aug 2019 21:26:09 +0000 (14:26 -0700)]
Merge branch 'ds/commit-graph-octopus-fix'

commit-graph did not handle commits with more than two parents
correctly, which has been corrected.

* ds/commit-graph-octopus-fix:
  commit-graph: fix bug around octopus merges

18 months agot0000: reword comments for "local" test
Jeff King [Thu, 8 Aug 2019 09:37:33 +0000 (05:37 -0400)]
t0000: reword comments for "local" test

Commit 01d3a526ad (t0000: check whether the shell supports the "local"
keyword, 2017-10-26) added a test to gather data on whether people run
the test suite with shells that don't support "local".

After almost two years, nobody has complained, and several other uses
have cropped up in test-lib-functions.sh. Let's declare it acceptable to
use.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agot: decrease nesting in test_oid_to_path
Jonathan Nieder [Thu, 8 Aug 2019 06:56:14 +0000 (23:56 -0700)]
t: decrease nesting in test_oid_to_path

t1410.3 ("corrupt and checks") fails when run using dash versions
before 0.5.8, with a cryptic message:

mv: cannot stat '.git/objects//e84adb2704cbd49549e52169b4043871e13432': No such file or directory

The function generating that path:

test_oid_to_path () {
echo "${1%${1#??}}/${1#??}"
}

which is supposed to produce a result like

12/3456789....

But a dash bug[*] causes it to instead expand to

/3456789...

The stream of symbols that makes up this function is hard for humans
to follow, too.  The complexity mostly comes from the repeated use of
the expression ${1#??} for the basename of the loose object.  Use a
variable instead --- nowadays, the dialect of shell used by Git
permits local variables, so this is cheap.

An alternative way to work around [*] is to remove the double-quotes
around test_oid_to_path's return value.  That makes the expression
easier for dash to read, but harder for humans.  Let's prefer the
rephrasing that's helpful for humans, too.

Noticed by building on Ubuntu trusty, which uses dash 0.5.7.

[*] Fixed by v0.5.8~13 ("[EXPAND] Propagate EXP_QPAT in subevalvar, 2013-08-23).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agoMerge branch 'py/call-do-quit-before-exit' of github.com:gitster/git-gui into py...
Junio C Hamano [Wed, 7 Aug 2019 20:26:06 +0000 (13:26 -0700)]
Merge branch 'py/call-do-quit-before-exit' of github.com:gitster/git-gui into py/git-gui-do-quit

* 'py/call-do-quit-before-exit' of github.com:gitster/git-gui:
  git-gui: call do_quit before destroying the main window

18 months agogit-gui: call do_quit before destroying the main window
Pratyush Yadav [Sun, 4 Aug 2019 14:39:19 +0000 (20:09 +0530)]
git-gui: call do_quit before destroying the main window

If the toplevel window for the window being destroyed is the main window
(aka "."), then simply destroying it means the cleanup tasks are not
executed (like saving the commit message buffer, saving window state,
etc.)

All this is handled by do_quit.  Call it instead of directly
destroying the main window. For other toplevel windows, the old
behavior remains.

Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agosha1-file: release strbuf after use
René Scharfe [Wed, 7 Aug 2019 11:15:25 +0000 (13:15 +0200)]
sha1-file: release strbuf after use

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agotest-dir-iterator: use path argument directly
René Scharfe [Wed, 7 Aug 2019 11:15:20 +0000 (13:15 +0200)]
test-dir-iterator: use path argument directly

Avoid allocating and leaking a strbuf for holding a verbatim copy of the
path argument and pass the latter directly to dir_iterator_begin()
instead.

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agodir-iterator: release strbuf after use
René Scharfe [Wed, 7 Aug 2019 11:15:14 +0000 (13:15 +0200)]
dir-iterator: release strbuf after use

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agocommit-graph: release strbufs after use
René Scharfe [Wed, 7 Aug 2019 11:15:02 +0000 (13:15 +0200)]
commit-graph: release strbufs after use

Signed-off-by: René Scharfe <l.s.r@web.de>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agonedmalloc: avoid compiler warning about unused value
René Scharfe [Wed, 7 Aug 2019 13:09:02 +0000 (15:09 +0200)]
nedmalloc: avoid compiler warning about unused value

Cast the evaluated value of the macro INITIAL_LOCK to void to instruct
the compiler that we're not interested in said value nor the following
warning:

In file included from compat/nedmalloc/nedmalloc.c:63:
compat/nedmalloc/malloc.c.h: In function ‘init_user_mstate’:
compat/nedmalloc/malloc.c.h:1706:62: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
 1706 | #define INITIAL_LOCK(sl)      (memset(sl, 0, sizeof(MLOCK_T)), 0)
      |                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
compat/nedmalloc/malloc.c.h:5020:3: note: in expansion of macro ‘INITIAL_LOCK’
 5020 |   INITIAL_LOCK(&m->mutex);
      |   ^~~~~~~~~~~~

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agonedmalloc: do assignments only after the declaration section
René Scharfe [Wed, 7 Aug 2019 13:08:51 +0000 (15:08 +0200)]
nedmalloc: do assignments only after the declaration section

Avoid the following compiler warning:

In file included from compat/nedmalloc/nedmalloc.c:63:
compat/nedmalloc/malloc.c.h: In function ‘pthread_release_lock’:
compat/nedmalloc/malloc.c.h:1759:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
 1759 |     volatile unsigned int* lp = &sl->l;
      |     ^~~~~~~~

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agoconfig: stop checking whether the_repository is NULL
Jeff King [Tue, 6 Aug 2019 12:27:58 +0000 (08:27 -0400)]
config: stop checking whether the_repository is NULL

Since the previous commit, our invariant that the_repository is never
NULL is restored, and we can stop being defensive in include_by_branch().

We can confirm the fix by showing that an onbranch config include will
not cause a segfault when run outside a git repository. I've put this in
t1309-early-config since it's related to the case added by 85fe0e800c
(config: work around bug with includeif:onbranch and early config,
2019-07-31), though technically the issue was with
read_very_early_config() and not read_early_config().

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agocommon-main: delay trace2 initialization
Jeff King [Tue, 6 Aug 2019 12:27:26 +0000 (08:27 -0400)]
common-main: delay trace2 initialization

We initialize the trace2 system in the common main() function so that
all programs (even ones that aren't builtins) will enable tracing. But
trace2 startup is relatively heavy-weight, as we have to actually read
on-disk config to decide whether to trace. This can cause unexpected
interactions with other common-main initialization. For instance, we'll
end up in the config code before calling initialize_the_repository(),
and the usual invariant that the_repository is never NULL will not hold.

Let's push the trace2 initialization further down in common-main, to
just before we execute cmd_main(). The other parts of the initialization
are much more self-contained and less likely to call library code that
depends on those kinds of invariants.

Originally the trace2 code tried to start as early as possible to get
accurate timings. But the timer initialization was split out from the
config reading in a089724958 (trace2: refactor setting process starting
time, 2019-04-15), so there shouldn't be any impact from this patch.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agot1309: use short branch name in includeIf.onbranch test
Jeff King [Tue, 6 Aug 2019 12:26:45 +0000 (08:26 -0400)]
t1309: use short branch name in includeIf.onbranch test

Commit 85fe0e800c (config: work around bug with includeif:onbranch and
early config, 2019-07-31) tests that our early config-reader does not
access the file mentioned by includeIf.onbranch:refs/heads/master.path.
But it would never do so even if the feature were implemented, since the
onbranch matching code uses the short refname "master".

The test still serves its purpose, since the bug fixed by 85fe0e800c is
actually that we hit a BUG() before even deciding whether to match the
ref. But let's use the correct name to avoid confusion (and which we'll
eventually want to trigger once we do the "real" fix described in that
commit).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agogitcli: document --end-of-options
Jeff King [Tue, 6 Aug 2019 14:40:30 +0000 (10:40 -0400)]
gitcli: document --end-of-options

Now that --end-of-options is available for any users of
setup_revisions() or parse_options(), which should be effectively
everywhere, we can guide people to use it for all their disambiguating
needs.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agoparse-options: allow --end-of-options as a synonym for "--"
Jeff King [Tue, 6 Aug 2019 14:40:16 +0000 (10:40 -0400)]
parse-options: allow --end-of-options as a synonym for "--"

The revision option parser recently learned about --end-of-options, but
that's not quite enough for all callers. Some of them, like git-log,
pick out some options using parse_options(), and then feed the remainder
to setup_revisions(). For those cases we need to stop parse_options()
from finding more options when it sees --end-of-options, and to retain
that option in argv so that setup_revisions() can see it as well.

Let's handle this the same as we do "--". We can even piggy-back on the
handling of PARSE_OPT_KEEP_DASHDASH, because any caller that wants to
retain one will want to retain the other.

I've included two tests here. The "log" test covers "--source", which is
one of the options it handles with parse_options(), and would fail
before this patch. There's also a test that uses the parse-options
helper directly. That confirms that the option is handled correctly even
in cases without KEEP_DASHDASH or setup_revisions(). I.e., it is safe to
use --end-of-options in place of "--" in other programs.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agorevision: allow --end-of-options to end option parsing
Jeff King [Tue, 6 Aug 2019 14:39:58 +0000 (10:39 -0400)]
revision: allow --end-of-options to end option parsing

There's currently no robust way to tell Git that a particular option is
meant to be a revision, and not an option. So if you have a branch
"refs/heads/--foo", you cannot just say:

  git rev-list --foo

You can say:

  git rev-list refs/heads/--foo

But that breaks down if you don't know the refname, and in particular if
you're a script passing along a value from elsewhere. In most programs,
you can use "--" to end option parsing, like this:

  some-prog -- "$revision"

But that doesn't work for the revision parser, because "--" is already
meaningful there: it separates revisions from pathspecs. So we need some
other marker to separate options from revisions.

This patch introduces "--end-of-options", which serves that purpose:

  git rev-list --oneline --end-of-options "$revision"

will work regardless of what's in "$revision" (well, if you say "--" it
may fail, but it won't do something dangerous, like triggering an
unexpected option).

The name is verbose, but that's probably a good thing; this is meant to
be used for scripted invocations where readability is more important
than terseness.

One alternative would be to introduce an explicit option to mark a
revision, like:

  git rev-list --oneline --revision="$revision"

That's slightly _more_ informative than this commit (because it makes
even something silly like "--" unambiguous). But the pattern of using a
separator like "--" is well established in git and in other commands,
and it makes some scripting tasks simpler like:

  git rev-list --end-of-options "$@"

There's no documentation in this patch, because it will make sense to
describe the feature once it is available everywhere (and support will
be added in further patches).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agol10n: reformat some localized strings for v2.23.0
Jean-Noël Avila [Tue, 6 Aug 2019 17:19:52 +0000 (19:19 +0200)]
l10n: reformat some localized strings for v2.23.0

Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agomerge-recursive: avoid directory rename detection in recursive case
Elijah Newren [Mon, 5 Aug 2019 22:33:50 +0000 (15:33 -0700)]
merge-recursive: avoid directory rename detection in recursive case

Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory
rename detection default", 2019-04-05), the default handling with
directory rename detection was to report a conflict and leave unstaged
entries in the index.  However, when creating a virtual merge base in
the recursive case, we absolutely need a tree, and the only way a tree
can be written is if we have no unstaged entries -- otherwise we hit a
BUG().

There are a few fixes possible here which at least fix the BUG(), but
none of them seem optimal for other reasons; see the comments with the
new testcase 13e in t6043 for details (which testcase triggered a BUG()
prior to this patch).  As such, just opt for a very conservative and
simple choice that is still relatively reasonable: have the recursive
case treat 'conflict' as 'false' for opt->detect_directory_renames.

Reported-by: Emily Shaffer <emilyshaffer@google.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agol10n: vi.po (4676t): Updated Vietnamese translation
Tran Ngoc Quan [Tue, 6 Aug 2019 07:30:57 +0000 (14:30 +0700)]
l10n: vi.po (4676t): Updated Vietnamese translation

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
18 months agotests: show the test name and number at the start of verbose output
SZEDER Gábor [Mon, 5 Aug 2019 21:04:47 +0000 (23:04 +0200)]
tests: show the test name and number at the start of verbose output

The verbose output of every test looks something like this:

  expecting success:
          echo content >file &&
          git add file &&
          git commit -m "add file"

  [master (root-commit) d1fbfbd] add file
   Author: A U Thor <author@example.com>
   1 file changed, 1 insertion(+)
   create mode 100644 file
  ok 1 - commit works

i.e. first an "expecting success" (or "checking known breakage") line
followed by the commands to be executed, then the output of those
comamnds, and finally an "ok"/"not ok" line containing the test name.
Note that the test's name is only shown at the very end.

With '-x' tracing enabled and/or in longer tests the verbose output
might be several screenfulls long, making it harder than necessary to
find where the output of the test with a given name starts (especially
when the outputs to different file descriptors are racing, and the
"expecting success"/command block arrives earlier than the "ok" line
of the previous test).

Print the test name at the start of the test's verbose output, i.e. at
the end of the "expecting success" and "checking known breakage"
lines, to make the start of a particular test a bit easier to
recognize.  Also print the test script and test case numbers, to help
those poor souls who regularly have to scan through the combined
verbose output of several test scripts.

So the dummy test above would start like this:

  expecting success of 9999.1 'commit works':
          echo content >file &&
  [...]

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agot0000-basic: use realistic test script names in the verbose tests
SZEDER Gábor [Mon, 5 Aug 2019 21:04:46 +0000 (23:04 +0200)]
t0000-basic: use realistic test script names in the verbose tests

Our test scripts are named something like 't1234-command.sh', but the
script names used in 't0000-basic.sh' don't follow this naming
convention.  Normally this doesn't matter, because the test scripts
themselves don't care how they are called.  However, the next patch
will start to include the test number in the test's verbose output, so
the test script's name will matter in the two tests checking the
verbose output.

Update the tests 'test --verbose' and 'test --verbose-only' to follow
out test script naming convention.

Leave the other tests in 't0000' unchanged: changing the names of
their test scripts would be only pointless code churn.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agocommit-graph: fix bug around octopus merges
Derrick Stolee [Mon, 5 Aug 2019 16:43:41 +0000 (09:43 -0700)]
commit-graph: fix bug around octopus merges

In 1771be90 "commit-graph: merge commit-graph chains" (2019-06-18),
the method sort_and_scan_merged_commits() was added to merge the
commit lists of two commit-graph files in the incremental format.
Unfortunately, there was an off-by-one error in that method around
incrementing num_extra_edges, which leads to an incorrect offset
for the base graph chunk.

When we store an octopus merge in the commit-graph file, we store
the first parent in the normal place, but use the second parent
position to point into the "extra edges" chunk where the remaining
parents exist. This means we should be adding "num_parents - 1"
edges to this list, not "num_parents - 2". That is the basic error.

The reason this was not caught in the test suite is more subtle.
In 5324-split-commit-graph.sh, we test creating an octopus merge
and adding it to the tip of a commit-graph chain, then verify the
result. This _should_ have caught the problem, except that when
we load the commit-graph files we were overly careful to not fail
when the commit-graph chain does not match. This care was on
purpose to avoid race conditions as one process reads the chain
and another process modifies it. In such a case, the reading
process outputs the following message to stderr:

warning: commit-graph chain does not match

These warnings are output in the test suite, but ignored. By
checking the stderr of `git commit-graph verify` to include
the expected progress output, it will now catch this error.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agocommit-graph: error out on invalid commit oids in 'write --stdin-commits'
SZEDER Gábor [Mon, 5 Aug 2019 08:02:40 +0000 (10:02 +0200)]
commit-graph: error out on invalid commit oids in 'write --stdin-commits'

While 'git commit-graph write --stdin-commits' expects commit object
ids as input, it accepts and silently skips over any invalid commit
object ids, and still exits with success:

  # nonsense
  $ echo not-a-commit-oid | git commit-graph write --stdin-commits
  $ echo $?
  0
  # sometimes I forgot that refs are not good...
  $ echo HEAD | git commit-graph write --stdin-commits
  $ echo $?
  0
  # valid tree OID, but not a commit OID
  $ git rev-parse HEAD^{tree} | git commit-graph write --stdin-commits
  $ echo $?
  0
  $ ls -l .git/objects/info/commit-graph
  ls: cannot access '.git/objects/info/commit-graph': No such file or directory

Check that all input records are indeed valid commit object ids and
return with error otherwise, the same way '--stdin-packs' handles
invalid input; see e103f7276f (commit-graph: return with errors during
write, 2019-06-12).

Note that it should only return with error when encountering an
invalid commit object id coming from standard input.  However,
'--reachable' uses the same code path to process object ids pointed to
by all refs, and that includes tag object ids as well, which should
still be skipped over.  Therefore add a new flag to 'enum
commit_graph_write_flags' and a corresponding field to 'struct
write_commit_graph_context', so we can differentiate between those two
cases.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agocommit-graph: turn a group of write-related macro flags into an enum
SZEDER Gábor [Mon, 5 Aug 2019 08:02:39 +0000 (10:02 +0200)]
commit-graph: turn a group of write-related macro flags into an enum

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agot5318-commit-graph: use 'test_expect_code'
SZEDER Gábor [Mon, 5 Aug 2019 08:02:38 +0000 (10:02 +0200)]
t5318-commit-graph: use 'test_expect_code'

In 't5318-commit-graph.sh' the test 'close with correct error on bad
input' manually verifies the exit code of a 'git commit-graph write'
command.

Use 'test_expect_code' instead.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agorestore: fix typo in docs
William Chargin [Sat, 3 Aug 2019 22:04:58 +0000 (15:04 -0700)]
restore: fix typo in docs

Signed-off-by: William Chargin <wchargin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agodoc: typo: s/can not/cannot/ and s/is does/does/
Mark Rushakoff [Sat, 3 Aug 2019 05:33:51 +0000 (22:33 -0700)]
doc: typo: s/can not/cannot/ and s/is does/does/

"Can not" suggests one has the option to not do something, whereas
"cannot" more strongly suggests something is disallowed or impossible.

Noticed "can not", mistakenly used instead of "cannot" in git help
glossary, then ran git grep 'can not' and found many other instances.
Only files in the Documentation folder were modified.

'Can not' also occurs in some source code comments and some test
assertion messages, and there is an error message and translation "can
not move directory into itself" which I may fix and submit separately
from the documentation change.

Also noticed and fixed "is does" in git help fetch, but there are no
other occurrences of that typo according to git grep.

Signed-off-by: Mark Rushakoff <mark.rushakoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agoMerge branch 'master' of https://github.com/Softcatala/git-po
Jiang Xin [Sat, 3 Aug 2019 13:09:13 +0000 (21:09 +0800)]
Merge branch 'master' of https://github.com/Softcatala/git-po

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

18 months agoMerge branch 'update-italian-translation' of github.com:AlessandroMenti/git-po
Jiang Xin [Sat, 3 Aug 2019 13:07:05 +0000 (21:07 +0800)]
Merge branch 'update-italian-translation' of github.com:AlessandroMenti/git-po

* 'update-italian-translation' of github.com:AlessandroMenti/git-po:
  l10n: it.po: update the Italian translation for v2.23.0

18 months agol10n: Update Catalan translation
Jordi Mas [Sat, 3 Aug 2019 07:27:05 +0000 (09:27 +0200)]
l10n: Update Catalan translation

Signed-off-by: Jordi Mas <jmas@softcatala.org>
18 months agoGit 2.23-rc1 v2.23.0-rc1
Junio C Hamano [Fri, 2 Aug 2019 20:12:24 +0000 (13:12 -0700)]
Git 2.23-rc1

Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agoMerge branch 'sg/fsck-config-in-doc'
Junio C Hamano [Fri, 2 Aug 2019 20:12:03 +0000 (13:12 -0700)]
Merge branch 'sg/fsck-config-in-doc'

Doc update.

* sg/fsck-config-in-doc:
  Documentation/git-fsck.txt: include fsck.* config variables

18 months agoMerge branch 'js/visual-studio'
Junio C Hamano [Fri, 2 Aug 2019 20:12:02 +0000 (13:12 -0700)]
Merge branch 'js/visual-studio'

Support building Git with Visual Studio

The bits about .git/branches/* have been dropped from the series.
We may want to drop the support for it, but until that happens, the
tests should rely on the existence of the support to pass.

* js/visual-studio: (23 commits)
  git: avoid calling aliased builtins via their dashed form
  bin-wrappers: append `.exe` to target paths if necessary
  .gitignore: ignore Visual Studio's temporary/generated files
  .gitignore: touch up the entries regarding Visual Studio
  vcxproj: also link-or-copy builtins
  msvc: add a Makefile target to pre-generate the Visual Studio solution
  contrib/buildsystems: add a backend for modern Visual Studio versions
  contrib/buildsystems: handle options starting with a slash
  contrib/buildsystems: also handle -lexpat
  contrib/buildsystems: handle libiconv, too
  contrib/buildsystems: handle the curl library option
  contrib/buildsystems: error out on unknown option
  contrib/buildsystems: optionally capture the dry-run in a file
  contrib/buildsystems: redirect errors of the dry run into a log file
  contrib/buildsystems: ignore gettext stuff
  contrib/buildsystems: handle quoted spaces in filenames
  contrib/buildsystems: fix misleading error message
  contrib/buildsystems: ignore irrelevant files in Generators/
  contrib/buildsystems: ignore invalidcontinue.obj
  Vcproj.pm: urlencode '<' and '>' when generating VC projects
  ...

18 months agoMerge branch 'jc/log-mailmap-flip-defaults'
Junio C Hamano [Fri, 2 Aug 2019 20:12:02 +0000 (13:12 -0700)]
Merge branch 'jc/log-mailmap-flip-defaults'

Hotfix for making "git log" use the mailmap by default.

* jc/log-mailmap-flip-defaults:
  log: really flip the --mailmap default
  log: flip the --mailmap default unconditionally

18 months agoMerge branch 'js/early-config-with-onbranch'
Junio C Hamano [Fri, 2 Aug 2019 20:12:02 +0000 (13:12 -0700)]
Merge branch 'js/early-config-with-onbranch'

The recently added [includeif "onbranch:branch"] feature does not
work well with an early config mechanism, as it attempts to find
out what branch we are on before we even haven't located the git
repository.  The inclusion during early config scan is ignored to
work around this issue.

* js/early-config-with-onbranch:
  config: work around bug with includeif:onbranch and early config

18 months agorestore: add test for deleted ita files
Varun Naik [Thu, 1 Aug 2019 16:09:10 +0000 (09:09 -0700)]
restore: add test for deleted ita files

`git restore --staged` uses the same machinery as `git checkout HEAD`,
so there should be a similar test case for "restore" as the existing
test case for "checkout" with deleted ita files.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Varun Naik <vcnaik94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agocheckout.c: unstage empty deleted ita files
Varun Naik [Fri, 2 Aug 2019 16:28:52 +0000 (09:28 -0700)]
checkout.c: unstage empty deleted ita files

It is possible to delete a committed file from the index and then add it
as intent-to-add. After `git checkout HEAD <pathspec>`, the file should
be identical in the index and HEAD. The command already works correctly
if the file has contents in HEAD. This patch provides the desired
behavior even when the file is empty in HEAD.

`git checkout HEAD <pathspec>` calls tree.c:read_tree_1(), with fn
pointing to checkout.c:update_some(). update_some() creates a new cache
entry but discards it when its mode and oid match those of the old
entry. A cache entry for an ita file and a cache entry for an empty file
have the same oid. Therefore, an empty deleted ita file previously
passed both of these checks, and the new entry was discarded, so the
file remained unchanged in the index. After this fix, if the file is
marked as ita in the cache, then we avoid discarding the new entry and
add the new entry to the cache instead.

This change should not affect newly added ita files. For those, inside
tree.c:read_tree_1(), tree_entry_interesting() returns
entry_not_interesting, so fn is never called.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Varun Naik <vcnaik94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agopack-refs: always refresh after taking the lock file
Sun Chao [Wed, 31 Jul 2019 18:35:44 +0000 (02:35 +0800)]
pack-refs: always refresh after taking the lock file

When a packed ref is deleted, the whole packed-refs file is
rewritten to omit the ref that no longer exists. However if another
gc command is running and calls `pack-refs --all` simultaneously,
there is a chance that a ref that was just updated lose the newly
created commits.

Through these steps, losing commits on newly updated refs can be
demonstrated:

  # step 1: compile git without `USE_NSEC` option
  Some kernel releases do enable it by default while some do
  not. And if we compile git without `USE_NSEC`, it will be easier
  demonstrated by the following steps.

  # step 2: setup a repository and add the first commit
  git init repo &&
  (cd repo &&
   git config core.logallrefupdates true &&
   git commit --allow-empty -m foo)

  # step 3: in one terminal, repack the refs repeatedly
  cd repo &&
  while true
  do
    git pack-refs --all
  done

  # step 4: in another terminal, simultaneously update the
  # master with update-ref, and create and delete an
  # unrelated ref also with update-ref
  cd repo &&
  while true
  do
    us=$(git commit-tree -m foo -p HEAD HEAD^{tree}) &&
    git update-ref refs/heads/newbranch $us &&
    git update-ref refs/heads/master $us &&
    git update-ref -d refs/heads/newbranch &&
    them=$(git rev-parse master) &&
    if test "$them" != "$us"
    then
      echo >&2 "lost commit: $us"
      exit 1
    fi
    # eye candy
    printf .
  done

Though we have the packed-refs lock file and loose refs lock
files to avoid updating conflicts, a ref will lost its newly
commits if racy stat-validity of `packed-refs` file happens
(which is quite same as the racy-git described in
`Documentation/technical/racy-git.txt`), the following
specific set of operations demonstrates the problem:

  1. Call `pack-refs --all` to pack all the loose refs to
     packed-refs, and let say the modify time of the
     packed-refs is DATE_M.

  2. Call `update-ref` to update a new commit to master while
     it is already packed.  the old value (let us call it
     OID_A) remains in the packed-refs file and write the new
     value (let us call it OID_B) to $GIT_DIR/refs/heads/master.

  3. Call `update-ref -d` within the same DATE_M from the 1th
     step to delete a different ref newbranch which is packed
     in the packed-refs file. It check newbranch's oid from
     packed-refs file without locking it.

     Meanwhile it keeps a snapshot of the packed-refs file in
     memory and record the file's attributes with the snapshot.
     The oid of master in the packed-refs's snapshot is OID_A.

  4. Call a new `pack-refs --all` to pack the loose refs, the
     oid of master in packe-refs file is OID_B, and the loose
     refs $GIT_DIR/refs/heads/master is removed. Let's say
     the `pack-refs --all` is very quickly done and the new
     packed-refs file's modify time is still DATE_M, and it
     has the same file size, even the same inode.

  5. 3th step now goes on after checking the newbranch, it
     begin to rewrite the packed-refs file. After get the
     lock file of packed-ref file, it checks it's on-disk
     file attributes with the snapshot, suck as the timestamp,
     the file size and the inode value. If they are both the
     same values, and the snapshot is not refreshed.

     Because the loose ref of master is removed by 4th step,
     `update-ref -d` will updates the new packed-ref to disk
     which contains master with the oid OID_A. So now the
     newly commit OID_B of master is lost.

The best path forward is just always refreshing after take
the lock file of `packed-refs` file. Traditionally we avoided
that because refreshing it implied parsing the whole file.
But these days we mmap it, so it really is just an extra
open()/mmap() and a quick read of the header. That doesn't seem
like an outrageous cost to pay when we're already taking the lock.

Signed-off-by: Sun Chao <sunchao9@huawei.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Sun Chao <sunchao9@huawei.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agolog: really flip the --mailmap default
Junio C Hamano [Thu, 1 Aug 2019 21:48:34 +0000 (14:48 -0700)]
log: really flip the --mailmap default

Update the docs, test the interaction between the new default,
configuration and command line option, in addition to actually
flipping the default.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agot: warn against adding non-httpd-specific tests after sourcing 'lib-httpd'
SZEDER Gábor [Thu, 1 Aug 2019 15:53:09 +0000 (17:53 +0200)]
t: warn against adding non-httpd-specific tests after sourcing 'lib-httpd'

We have a couple of test scripts that are not completely
httpd-specific, but do run a few httpd-specific tests at the end.
These test scripts source 'lib-httpd.sh' somewhere mid-script, which
then skips all the rest of the test script if the dependencies for
running httpd tests are not fulfilled.

As the previous two patches in this series show, already on two
occasions non-httpd-specific tests were appended at the end of such
test scripts, and, consequently, they were skipped as well when httpd
tests couldn't be run.

Add a comment at the end of these test scripts to warn against adding
non-httpd-specific tests at the end, in the hope that they will help
prevent similar issues in the future.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agotree-walk: harden make_traverse_path() length computations
Jeff King [Wed, 31 Jul 2019 04:38:25 +0000 (00:38 -0400)]
tree-walk: harden make_traverse_path() length computations

The make_traverse_path() function isn't very careful about checking its
output buffer boundaries. In fact, it doesn't even _know_ the size of
the buffer it's writing to, and just assumes that the caller used
traverse_path_len() correctly. And even then we assume that our
traverse_info.pathlen components are all correct, and just blindly write
into the buffer.

Let's improve this situation a bit:

  - have the caller pass in their allocated buffer length, which we'll
    check against our own computations

  - check for integer underflow as we do our backwards-insertion of
    pathnames into the buffer

  - check that we do not run out items in our list to traverse before
    we've filled the expected number of bytes

None of these should be triggerable in practice (especially since our
switch to size_t everywhere in a previous commit), but it doesn't hurt
to check our assumptions.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agotree-walk: add a strbuf wrapper for make_traverse_path()
Jeff King [Wed, 31 Jul 2019 04:38:23 +0000 (00:38 -0400)]
tree-walk: add a strbuf wrapper for make_traverse_path()

All but one of the callers of make_traverse_path() allocate a new heap
buffer to store the path. Let's give them an easy way to write to a
strbuf, which saves them from computing the length themselves (which is
especially tricky when they want to add to the path). It will also make
it easier for us to change the make_traverse_path() interface in a
future patch to improve its bounds-checking.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agotree-walk: accept a raw length for traverse_path_len()
Jeff King [Wed, 31 Jul 2019 04:38:20 +0000 (00:38 -0400)]
tree-walk: accept a raw length for traverse_path_len()

We take a "struct name_entry", but only care about the length of the
path name. Let's just take that length directly, making it easier to use
the function from callers that sometimes do not have a name_entry at
all.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agotree-walk: use size_t consistently
Jeff King [Wed, 31 Jul 2019 04:38:18 +0000 (00:38 -0400)]
tree-walk: use size_t consistently

We store and manipulate the cumulative traverse_info.pathlen as an
"int", which can overflow when we are fed ridiculously long pathnames
(e.g., ones at the edge of 2GB or 4GB, even if the individual tree entry
names are smaller than that). The results can be confusing, though
after some prodding I was not able to use this integer overflow to cause
an under-allocated buffer.

Let's consistently use size_t to generate and store these, and make
sure our addition doesn't overflow.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agot5703: run all non-httpd-specific tests before sourcing 'lib-httpd.sh'
SZEDER Gábor [Thu, 1 Aug 2019 15:53:08 +0000 (17:53 +0200)]
t5703: run all non-httpd-specific tests before sourcing 'lib-httpd.sh'

't5703-upload-pack-ref-in-want.sh' sources 'lib-httpd.sh' near the end
to run a couple of httpd-specific tests, but 'lib-httpd.sh' skips all
the rest of the test script if the dependencies for running httpd
tests are not fulfilled.  However, the last six tests in 't5703' are
not httpd-specific, but they are skipped as well when httpd tests
can't be run.

Move these six tests earlier in the test script, before 'lib-httpd.sh'
is sourced, so they will be run even when httpd tests aren't.  Note
that this is not merely a pure code movement, because the setup test
case for the httpd tests needed an additional 'rm -rf
"$LOCAL_PRISTINE"' to clean up a directory left behind by the moved
non-httpd-specific tests.

Also add a comment at the end of this test script to warn against
adding non-httpd-specific tests at the end, in the hope that it will
help prevent similar issues in the future.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agot5510-fetch: run non-httpd-specific test before sourcing 'lib-httpd.sh'
SZEDER Gábor [Thu, 1 Aug 2019 15:53:07 +0000 (17:53 +0200)]
t5510-fetch: run non-httpd-specific test before sourcing 'lib-httpd.sh'

't5510-fetch.sh' sources 'lib-httpd.sh' near the end to run a
httpd-specific test, but 'lib-httpd.sh' skips all the rest of the test
script if the dependencies for running httpd tests are not fulfilled.
Alas, recently cdbd70c437 (fetch: add --[no-]show-forced-updates
argument, 2019-06-18) appended a non-httpd-specific test at the end,
and this test is then skipped as well when httpd tests can't be run.

Move this new test earlier in the test script, before 'lib-httpd.sh'
is sourced, so it will be run even when httpd tests aren't.

Also add a comment at the end of this test script to warn against
adding non-httpd-specific tests at the end, in the hope that it will
help prevent similar issues in the future.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agoMerge branch 'jk/repack-silence-auto-bitmap-warning'
Junio C Hamano [Thu, 1 Aug 2019 16:10:50 +0000 (09:10 -0700)]
Merge branch 'jk/repack-silence-auto-bitmap-warning'

Squelch unneeded and misleading warnings from "repack" when the
command attempts to generate pack bitmaps without explicitly asked
for by the user.

* jk/repack-silence-auto-bitmap-warning:
  repack: simplify handling of auto-bitmaps and .keep files
  repack: silence warnings when auto-enabled bitmaps cannot be built
  t7700: clean up .keep file in bitmap-writing test

18 months agoMerge branch 'jk/sort-iter-test-output'
Junio C Hamano [Thu, 1 Aug 2019 16:10:50 +0000 (09:10 -0700)]
Merge branch 'jk/sort-iter-test-output'

* jk/sort-iter-test-output:
  t: sort output of hashmap iteration

18 months agoMerge branch 'jc/dir-iterator-test-fix'
Junio C Hamano [Thu, 1 Aug 2019 16:10:49 +0000 (09:10 -0700)]
Merge branch 'jc/dir-iterator-test-fix'

* jc/dir-iterator-test-fix:
  test-dir-iterator: do not assume errno values

18 months agoMerge branch 'bc/hash-independent-tests-part-4'
Junio C Hamano [Thu, 1 Aug 2019 16:10:49 +0000 (09:10 -0700)]
Merge branch 'bc/hash-independent-tests-part-4'

Update to the tests to help SHA-256 transition continues.

* bc/hash-independent-tests-part-4:
  t2203: avoid hard-coded object ID values
  t1710: make hash independent
  t1007: remove SHA1 prerequisites
  t0090: make test pass with SHA-256
  t0027: make hash size independent
  t6030: make test work with SHA-256
  t5000: make hash independent
  t1450: make hash size independent
  t1410: make hash size independent
  t: add helper to convert object IDs to paths

18 months agoRelNotes/2.23.0: fix a few typos and other minor issues
Martin Ågren [Thu, 1 Aug 2019 14:12:20 +0000 (16:12 +0200)]
RelNotes/2.23.0: fix a few typos and other minor issues

Fix the spelling of the new "--no-show-forced-updates" option that "git
fetch/pull" learned. Similarly, spell "--function-context" correctly and
fix a few typos, grammos and minor mistakes.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agoSync with maint
Junio C Hamano [Thu, 1 Aug 2019 16:00:46 +0000 (09:00 -0700)]
Sync with maint

* maint:
  RelNotes/2.21.1: typofix

18 months agoRelNotes/2.21.1: typofix
Martin Ågren [Thu, 1 Aug 2019 14:12:20 +0000 (16:12 +0200)]
RelNotes/2.21.1: typofix

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
18 months agolog: flip the --mailmap default unconditionally
Junio C Hamano [Thu, 1 Aug 2019 15:32:44 +0000 (08:32 -0700)]
log: flip the --mailmap default unconditionally

It turns out that being cautious to warn against upcoming default
change was an unpopular behaviour, and such a care can easily be
defeated by distro packagers to render it ineffective anyway.

Just flip the default, with only a mention in the release notes.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agol10n: it.po: update the Italian translation for v2.23.0
Alessandro Menti [Thu, 1 Aug 2019 07:32:52 +0000 (09:32 +0200)]
l10n: it.po: update the Italian translation for v2.23.0

Update the Italian translation for Git v2.23.0 (l10n round 1), as
well as adding some minor localization fixes.

Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>
19 months agoconfig: work around bug with includeif:onbranch and early config
Johannes Schindelin [Wed, 31 Jul 2019 20:06:42 +0000 (13:06 -0700)]
config: work around bug with includeif:onbranch and early config

Since 07b2c0eacac (config: learn the "onbranch:" includeIf condition,
2019-06-05), there is a potential catch-22 in the early config path: if
the `include.onbranch:` feature is used, Git assumes that the Git
directory has been initialized already. However, in the early config
code path that is not true.

One way to trigger this is to call the following commands in any
repository:

git config includeif.onbranch:refs/heads/master.path broken
git help -a

The symptom triggered by the `git help -a` invocation reads like this:

BUG: refs.c:1851: attempting to get main_ref_store outside of repository

Let's work around this, simply by ignoring the `includeif.onbranch:`
setting when parsing the config when the ref store has not been
initialized (yet).

Technically, there is a way to solve this properly: teach the refs
machinery to initialize the ref_store from a given gitdir/commondir pair
(which we _do_ have in the early config code path), and then use that in
`include_by_branch()`. This, however, is a pretty involved project, and
we're already in the feature freeze for Git v2.23.0.

Note: when calling above-mentioned two commands _outside_ of any Git
worktree (passing the `--global` flag to `git config`, as there is
obviously no repository config available), at the point when
`include_by_branch()` is called, `the_repository` is `NULL`, therefore
we have to be extra careful not to dereference it in that case.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agoA few more last-minute fixes
Junio C Hamano [Wed, 31 Jul 2019 21:45:42 +0000 (14:45 -0700)]
A few more last-minute fixes

Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agoMerge branch 'cb/xdiff-no-system-includes-in-dot-c'
Junio C Hamano [Wed, 31 Jul 2019 21:38:56 +0000 (14:38 -0700)]
Merge branch 'cb/xdiff-no-system-includes-in-dot-c'

Compilation fix.

* cb/xdiff-no-system-includes-in-dot-c:
  xdiff: remove duplicate headers from xpatience.c
  xdiff: remove duplicate headers from xhistogram.c
  xdiff: drop system includes in xutils.c

19 months agoMerge branch 'jk/no-system-includes-in-dot-c'
Junio C Hamano [Wed, 31 Jul 2019 21:38:56 +0000 (14:38 -0700)]
Merge branch 'jk/no-system-includes-in-dot-c'

Compilation fix.

* jk/no-system-includes-in-dot-c:
  wt-status.h: drop stdio.h include
  verify-tag: drop signal.h include

19 months agotree-walk: drop oid from traverse_info
Jeff King [Wed, 31 Jul 2019 04:38:15 +0000 (00:38 -0400)]
tree-walk: drop oid from traverse_info

As the previous commit shows, the presence of an oid in each level of
the traverse_info is confusing and ultimately not necessary. Let's drop
it to make it clear that it will not always be set (as well as convince
us that it's unused, and let the compiler catch any merges with other
branches that do add new uses).

Since the oid is part of name_entry, we'll actually stop embedding a
name_entry entirely, and instead just separately hold the pathname, its
length, and the mode.

This makes the resulting code slightly more verbose as we have to pass
those elements around individually. But it also makes it more clear what
each code path is going to use (and in most of the paths, we really only
care about the pathname itself).

A few of these conversions are noisier than they need to be, as they
also take the opportunity to rename "len" to "namelen" for clarity
(especially where we also have "pathlen" or "ce_len" alongside).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agosetup_traverse_info(): stop copying oid
Jeff King [Wed, 31 Jul 2019 04:38:11 +0000 (00:38 -0400)]
setup_traverse_info(): stop copying oid

We assume that if setup_traverse_info() is passed a non-empty "base"
string, that string is pointing into a tree object and we can read the
object oid by skipping past the trailing NUL.

As it turns out, this is not true for either of the two calls, and we
may end up reading garbage bytes:

  1. In git-merge-tree, our base string is either empty (in which case
     we'd never run this code), or it comes from our traverse_path()
     helper. The latter overallocates a buffer by the_hash_algo->rawsz
     bytes, but then fills it with only make_traverse_path(), leaving
     those extra bytes uninitialized (but part of a legitimate heap
     buffer).

  2. In unpack_trees(), we pass o->prefix, which is some arbitrary
     string from the caller. In "git read-tree --prefix=foo", for
     instance, it will point to the command-line parameter, and we'll
     read 20 bytes past the end of the string.

Interestingly, tools like ASan do not detect (2) because the process
argv is part of a big pre-allocated buffer. So we're reading trash, but
it's trash that's probably part of the next argument, or the
environment.

You can convince it to fail by putting something like this at the
beginning of common-main.c's main() function:

  {
int i;
for (i = 0; i < argc; i++)
argv[i] = xstrdup_or_null(argv[i]);
  }

That puts the arguments into their own heap buffers, so running:

  make SANITIZE=address test

will find problems when "read-tree --prefix" is used (e.g., in t3030).

Doubly interesting, even with the hackery above, this does not fail
prior to ea82b2a085 (tree-walk: store object_id in a separate member,
2019-01-15). That commit switched setup_traverse_info() to actually
copying the hash, rather than simply pointing to it. That pointer was
always pointing to garbage memory, but that commit started actually
dereferencing the bytes, which is what triggers ASan.

That also implies that nobody actually cares about reading these oid
bytes anyway (or at least no path covered by our tests). And manual
inspection of the code backs that up (I'll follow this patch with some
cleanups that show definitively this is the case, but they're quite
invasive, so it's worth doing this fix on its own).

So let's drop the bogus hashcpy(), along with the confusing oversizing
in merge-tree.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agorepack: simplify handling of auto-bitmaps and .keep files
Jeff King [Wed, 31 Jul 2019 05:40:56 +0000 (01:40 -0400)]
repack: simplify handling of auto-bitmaps and .keep files

Commit 7328482253 (repack: disable bitmaps-by-default if .keep files
exist, 2019-06-29) taught repack to prefer disabling bitmaps to
duplicating objects (unless bitmaps were asked for explicitly).

But there's an easier way to do this: if we keep passing the
--honor-pack-keep flag to pack-objects when auto-enabling bitmaps, then
pack-objects already makes the same decision (it will disable bitmaps
rather than duplicate). Better still, pack-objects can actually decide
to do so based not just on the presence of a .keep file, but on whether
that .keep file actually impacts the new pack we're making (so if we're
racing with a push or fetch, for example, their temporary .keep file
will not block us from generating bitmaps if they haven't yet updated
their refs).

And because repack uses the --write-bitmap-index-quiet flag, we don't
have to worry about pack-objects generating confusing warnings when it
does see a .keep file. We can confirm this by tweaking the .keep test to
check repack's stderr.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agorepack: silence warnings when auto-enabled bitmaps cannot be built
Jeff King [Wed, 31 Jul 2019 05:39:27 +0000 (01:39 -0400)]
repack: silence warnings when auto-enabled bitmaps cannot be built

Depending on various config options, a full repack may not be able to
build a reachability bitmap index (e.g., if pack.packSizeLimit forces us
to write multiple packs). In these cases pack-objects may write a
warning to stderr.

Since 36eba0323d (repack: enable bitmaps by default on bare repos,
2019-03-14), we may generate these warnings even when the user did not
explicitly ask for bitmaps. This has two downsides:

  - it can be confusing, if they don't know what bitmaps are

  - a daemonized auto-gc will write this to its log file, and the
    presence of the warning may suppress further auto-gc (until
    gc.logExpiry has elapsed)

Let's have repack communicate to pack-objects that the choice to turn on
bitmaps was not made explicitly by the user, which in turn allows
pack-objects to suppress these warnings.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agot7700: clean up .keep file in bitmap-writing test
Jeff King [Wed, 31 Jul 2019 05:37:36 +0000 (01:37 -0400)]
t7700: clean up .keep file in bitmap-writing test

After our test snippet finishes, the .keep file is left in place, making
it hard to do further tests of the auto-bitmap-writing code (since it
suppresses the feature completely). Let's clean it up.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agot5510-fetch: fix negated 'test_i18ngrep' invocation
SZEDER Gábor [Tue, 30 Jul 2019 21:29:15 +0000 (23:29 +0200)]
t5510-fetch: fix negated 'test_i18ngrep' invocation

The test '--no-show-forced-updates' in 't5510-fetch.sh' added in
cdbd70c437 (fetch: add --[no-]show-forced-updates argument,
2019-06-18) runs '! test_i18ngrep ...'.  This is wrong, because when
running the test with GIT_TEST_GETTEXT_POISON=true, then
'test_i18ngrep' is basically a noop and always returns with success,
the leading ! turns that into a failure, which then fails the test.

Use 'test_i18ngrep ! ...' instead.

This went unnoticed by our GETTEXT_POISON CI builds, because those
builds don't run this test case: in those builds we don't install
Apache, and this test comes after 't5510' sources 'lib-httpd.sh',
which, consequently, skips all the remaining tests, including this
one.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agot: sort output of hashmap iteration
Jeff King [Wed, 31 Jul 2019 01:23:37 +0000 (21:23 -0400)]
t: sort output of hashmap iteration

The iteration order of a hashmap is undefined, and may depend on things
like the exact set of items added, or the table has been grown or
shrunk. In the case of an oidmap, it even depends on endianness, because
we take the oid hash by casting sha1 bytes directly into an unsigned
int.

Let's sort the test-tool output from any hash iterators. In the case of
t0011, this is just future-proofing. But for t0016, it actually fixes a
reported failure on the big-endian s390 and nonstop ports.

I didn't bother to teach the helper functions to optionally sort output.
They are short enough that it's simpler to just repeat them inline for
the iteration tests than it is to add a --sort option.

Reported-by: Randall S. Becker <rsbecker@nexbridge.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agol10n: sv.po: Update Swedish translation (4676t0f0u)
Peter Krefting [Wed, 31 Jul 2019 10:44:47 +0000 (12:44 +0200)]
l10n: sv.po: Update Swedish translation (4676t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
19 months agogrep: fix worktree case in submodules
Matheus Tavares [Tue, 30 Jul 2019 16:53:27 +0000 (13:53 -0300)]
grep: fix worktree case in submodules

Running git-grep with --recurse-submodules results in a cached grep for
the submodules even when --cached is not used. This makes all
modifications in submodules' tracked files be always ignored when
grepping. Solve that making git-grep respect the cached option when
invoking grep_cache() inside grep_submodule(). Also, add tests to
ensure that the desired behavior is performed.

Reported-by: Daniel Zaoui <jackdanielz@eyomi.org>
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agotest-dir-iterator: do not assume errno values
Junio C Hamano [Tue, 30 Jul 2019 17:45:48 +0000 (10:45 -0700)]
test-dir-iterator: do not assume errno values

A few tests printed 'errno' as an integer and compared with
hardcoded integers; this is obviously not portable.

A two things to note are:

 - the string obtained by strerror() is not portable, and cannot be
   used for the purpose of these tests.

 - there unfortunately isn't a portable way to map error numbers to
   error names.

As we only care about a few selected errors, just map the error
number to the name before emitting for comparison.

Reported-by: Randall S. Becker <rsbecker@nexbridge.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agol10n: git.pot: v2.23.0 round 1 (130 new, 35 removed)
Jiang Xin [Tue, 30 Jul 2019 01:59:56 +0000 (09:59 +0800)]
l10n: git.pot: v2.23.0 round 1 (130 new, 35 removed)

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

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
19 months agoMerge tag 'v2.23.0-rc0' of git://git.kernel.org/pub/scm/git/git
Jiang Xin [Tue, 30 Jul 2019 01:56:16 +0000 (09:56 +0800)]
Merge tag 'v2.23.0-rc0' of git://git./git/git

Git 2.23-rc0

* tag 'v2.23.0-rc0' of git://git.kernel.org/pub/scm/git/git: (420 commits)
  Git 2.23-rc0
  Merge fixes made on the 'master' front
  Flush fixes up to the third batch post 2.22.0
  The seventh batch
  git: mark cmd_rebase as requiring a worktree
  rebase: fix white-space
  xdiff: clamp function context indices in post-image
  grep: print the pcre2_jit_on value
  t6200: use test_commit_bulk
  travis-ci: build with GCC 4.8 as well
  The sixth batch
  clean: show an error message when the path is too long
  CodingGuidelines: spell out post-C89 rules
  README: fix rendering of text in angle brackets
  rm: resolving by removal is not a warning-worthy event
  transport-helper: avoid var decl in for () loop control
  stash: fix handling removed files with --keep-index
  mingw: support spawning programs containing spaces in their names
  gpg-interface: do not scan past the end of buffer
  tests: defang pager tests by explicitly disabling the log.mailmap warning
  ...

19 months agogit: avoid calling aliased builtins via their dashed form
Johannes Schindelin [Mon, 29 Jul 2019 20:08:16 +0000 (13:08 -0700)]
git: avoid calling aliased builtins via their dashed form

This is one of the few places where Git violates its own deprecation of
the dashed form. It is not necessary, either.

As of 595d59e2b53 (git.c: ignore pager.* when launching builtin as
dashed external, 2017-08-02), Git wants to ignore the pager.* config
setting when expanding aliases. So let's strip out the
check_pager_config(<command-name>) call from the copy-edited code.

This code actually made it into upstream git.git already, but it was
disabled in `#if 0 ... #endif` guards so far.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agobin-wrappers: append `.exe` to target paths if necessary
Johannes Schindelin [Mon, 29 Jul 2019 20:08:16 +0000 (13:08 -0700)]
bin-wrappers: append `.exe` to target paths if necessary

When compiling with Visual Studio, the projects' names are identical to
the executables modulo the extensions. Read: there will exist both a
directory called `git` as well as an executable called `git.exe` in the
end. Which means that the bin-wrappers *need* to target the `.exe` files
lest they try to execute directories.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months ago.gitignore: ignore Visual Studio's temporary/generated files
Johannes Schindelin [Mon, 29 Jul 2019 20:08:15 +0000 (13:08 -0700)]
.gitignore: ignore Visual Studio's temporary/generated files

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months ago.gitignore: touch up the entries regarding Visual Studio
Philip Oakley [Mon, 29 Jul 2019 20:08:14 +0000 (13:08 -0700)]
.gitignore: touch up the entries regarding Visual Studio

Add the Microsoft .manifest pattern, and do not anchor the 'Debug'
and 'Release' entries at the top-level directory, to allow for
multiple projects (one per target).

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agovcxproj: also link-or-copy builtins
Johannes Schindelin [Mon, 29 Jul 2019 20:08:13 +0000 (13:08 -0700)]
vcxproj: also link-or-copy builtins

The default location for `.exe` files linked by Visual Studio depends on
the mode (debug vs release) and the architecture. Meaning: after a full
build, there is a `git.exe` in the top-level directory, but none of the
built-ins are linked..

When running a test script in Git Bash, it therefore would pick up the
wrong, say, `git-receive-pack.exe`: the one installed at the same time
as the Git Bash.

Absolutely not what we want. We want to have confidence that our test
covers the MSVC-built Git executables, and not some random stuff.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agomsvc: add a Makefile target to pre-generate the Visual Studio solution
Johannes Schindelin [Mon, 29 Jul 2019 20:08:12 +0000 (13:08 -0700)]
msvc: add a Makefile target to pre-generate the Visual Studio solution

The entire idea of generating the VS solution makes only sense if we
generate it via Continuous Integration; otherwise potential users would
still have to download the entire Git for Windows SDK.

If we pre-generate the Visual Studio solution, Git can be built entirely
within Visual Studio, and the test scripts can be run in a regular Git
for Windows (e.g. the Portable Git flavor, which does not include a full
GCC toolchain and therefore weighs only about a tenth of Git for
Windows' SDK).

So let's just add a target in the Makefile that can be used to generate
said solution; The generated files will then be committed so that they
can be pushed to a branch ready to check out by Visual Studio users.

To make things even more useful, we also generate and commit other files
that are required to run the test suite, such as templates and
bin-wrappers: with this, developers can run the test suite in a regular
Git Bash after building the solution in Visual Studio.

Note: for this build target, we do not actually need to initialize the
`vcpkg` system, so we don't.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: add a backend for modern Visual Studio versions
Johannes Schindelin [Mon, 29 Jul 2019 20:08:12 +0000 (13:08 -0700)]
contrib/buildsystems: add a backend for modern Visual Studio versions

Based on the previous patches in this patch series that fixed the
generator for `.vcproj` files (which were used by Visual Studio prior to
2015 to define projects), this patch offers to generate project
definitions for neweer versions of Visual Studio (which use `.vcxproj`
files).

To that end, this patch copy-edits the generator of the `.vcproj`.

In addition, we now use the `vcpkg` system which allows us to build
Git's dependencies (e.g. curl, libexpat) conveniently. The support
scripts were introduced in the `jh/msvc` patch series, and with this
patch we initialize the `vcpkg` conditionally, in the `libgit` project's
`PreBuildEvent`. To allow for parallel building of the projects, we
therefore put `libgit` at the bottom of the project hierarchy.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: handle options starting with a slash
Johannes Schindelin [Mon, 29 Jul 2019 20:08:11 +0000 (13:08 -0700)]
contrib/buildsystems: handle options starting with a slash

With the recent changes to allow building with MSVC=1, we now pass the
/OPT:REF option to the compiler. This confuses the parser that wants to
turn the output of a dry run into project definitions for QMake and Visual
Studio:

Unhandled link option @ line 213: /OPT:REF at [...]

Let's just extend the code that passes through options that start with a
dash, so that it passes through options that start with a slash, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: also handle -lexpat
Johannes Schindelin [Mon, 29 Jul 2019 20:08:10 +0000 (13:08 -0700)]
contrib/buildsystems: also handle -lexpat

This is a dependency required for the non-smart HTTP backend.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: handle libiconv, too
Johannes Schindelin [Mon, 29 Jul 2019 20:08:10 +0000 (13:08 -0700)]
contrib/buildsystems: handle libiconv, too

Git's test suite shows tons of breakages unless Git is compiled
*without* NO_ICONV. That means, in turn, that we need to generate
build definitions *with* libiconv, which in turn implies that we
have to handle the -liconv option properly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: handle the curl library option
Philip Oakley [Mon, 29 Jul 2019 20:08:09 +0000 (13:08 -0700)]
contrib/buildsystems: handle the curl library option

Upon seeing the '-lcurl' option, point to the libcurl.lib.

While there, fix the elsif indentation.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: error out on unknown option
Johannes Schindelin [Mon, 29 Jul 2019 20:08:08 +0000 (13:08 -0700)]
contrib/buildsystems: error out on unknown option

One time too many did this developer call the `generate` script passing
a `--make-out=<PATH>` option that was happily ignored (because there
should be a space, not an equal sign, between `--make-out` and the
path).

And one time too many, this script not only ignored it but did not even
complain. Let's fix that.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: optionally capture the dry-run in a file
Philip Oakley [Mon, 29 Jul 2019 20:08:07 +0000 (13:08 -0700)]
contrib/buildsystems: optionally capture the dry-run in a file

Add an option for capturing the output of the make dry-run used in
determining the msvc-build structure for easy debugging.

You can use the output of `--make-out <path>` in subsequent runs via the
`--in <path>` option.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: redirect errors of the dry run into a log file
Philip Oakley [Mon, 29 Jul 2019 20:08:07 +0000 (13:08 -0700)]
contrib/buildsystems: redirect errors of the dry run into a log file

Rather than swallowing the errors, it is better to have them in a file.

To make it obvious what this is about, use the file name
'msvc-build-makedryerrors.txt'.

Further, if the output is empty, simply delete that file. As we target
Git for Windows' SDK (which, unlike its predecessor msysGit, offers Perl
versions newer than 5.8), we can use the quite readable syntax `if -f -z
$ErrsFile` (available in Perl >=5.10).

Note that the file will contain the new values of the GIT_VERSION and
GITGUI_VERSION if they were generated by the make file. They are omitted
if the release is tagged and indentically defined in their respective
GIT_VERSION_GEN file DEF_VER variables.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: ignore gettext stuff
Philip Oakley [Mon, 29 Jul 2019 20:08:06 +0000 (13:08 -0700)]
contrib/buildsystems: ignore gettext stuff

Git's build contains steps to handle internationalization. This caused
hiccups in the parser used to generate QMake/Visual Studio project files.

As those steps are irrelevant in this context, let's just ignore them.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: handle quoted spaces in filenames
Philip Oakley [Mon, 29 Jul 2019 20:08:05 +0000 (13:08 -0700)]
contrib/buildsystems: handle quoted spaces in filenames

The engine.pl script expects file names not to contain spaces. However,
paths with spaces are quite prevalent on Windows. Use shellwords() rather
than split() to parse them correctly.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: fix misleading error message
Philip Oakley [Mon, 29 Jul 2019 20:08:05 +0000 (13:08 -0700)]
contrib/buildsystems: fix misleading error message

The error message talked about a "lib option", but it clearly referred
to a link option.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: ignore irrelevant files in Generators/
Johannes Schindelin [Mon, 29 Jul 2019 20:08:04 +0000 (13:08 -0700)]
contrib/buildsystems: ignore irrelevant files in Generators/

The Generators/ directory can contain spurious files such as editors'
backup files. Even worse, there could be .swp files which are not even
valid Perl scripts.

Let's just ignore anything but .pm files in said directory.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19 months agocontrib/buildsystems: ignore invalidcontinue.obj
Philip Oakley [Mon, 29 Jul 2019 20:08:03 +0000 (13:08 -0700)]
contrib/buildsystems: ignore invalidcontinue.obj

Since 4b623d8 (MSVC: link in invalidcontinue.obj for better POSIX
compatibility, 2014-03-29), invalidcontinue.obj is linked in the MSVC
build, but it was not parsed correctly by the buildsystem. Ignore it, as
it is known to Visual Studio and will be handled elsewhere.

Also only substitute filenames ending with .o when generating the
source .c filename, otherwise we would start to expect .cbj files to
generate .obj files (which are not generated by our build)...

In the future there may be source files that produce .obj files
so keep the two issues (.obj files with & without source files)
separate.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Duncan Smart <duncan.smart@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>