Commit graph

57370 commits

Author SHA1 Message Date
SZEDER Gábor
7d4733c501 ci: fix GCC install in the Travis CI GCC OSX job
A few days ago Travis CI updated their existing OSX images, including
the Homebrew database in the xcode10.1 OSX image that we use.  Since
then installing dependencies in the 'osx-gcc' job fails when it tries
to link gcc@8:

  + brew link gcc@8
  Error: No such keg: /usr/local/Cellar/gcc@8

GCC8 is still installed but not linked to '/usr/local' in the updated
image, as it was before this update, but now we have to link it by
running 'brew link gcc'.  So let's do that then, and fall back to
linking gcc@8 if it doesn't, just to be sure.

Our builds on Azure Pipelines are unaffected by this issue.  The OSX
image over there doesn't contain the gcc@8 package, so we have to
'brew install' it, which already takes care of linking it to
'/usr/local'.  After that the 'brew link gcc' command added by this
patch fails, but the ||-chained fallback 'brew link gcc@8' command
succeeds with an "already linked" warning.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24 11:31:07 +09:00
Junio C Hamano
d81542e6f3 Eleventh batch
The tenth was at -rc0 ;-)

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 14:43:11 +09:00
Junio C Hamano
e0ff2d4c7e Merge branch 'cb/pcre2-chartables-leakfix'
Leakfix.

* cb/pcre2-chartables-leakfix:
  grep: avoid leak of chartables in PCRE2
  grep: make PCRE2 aware of custom allocator
  grep: make PCRE1 aware of custom allocator
2019-10-23 14:43:11 +09:00
Junio C Hamano
d45d771978 Merge branch 'bc/smart-http-atomic-push'
The atomic push over smart HTTP transport did not work, which has
been corrected.

* bc/smart-http-atomic-push:
  remote-curl: pass on atomic capability to remote side
2019-10-23 14:43:11 +09:00
Junio C Hamano
22dd22dce0 Merge branch 'wb/fsmonitor-bitmap-fix'
A segfault fix.

* wb/fsmonitor-bitmap-fix:
  fsmonitor: don't fill bitmap with entries to be removed
2019-10-23 14:43:10 +09:00
Junio C Hamano
2e215b7959 Merge branch 'sb/userdiff-dts'
Tweak userdiff patterns for dts.

* sb/userdiff-dts:
  userdiff: fix some corner cases in dts regex
2019-10-23 14:43:10 +09:00
Junio C Hamano
e3cf08361a Merge branch 'sg/progress-fix'
Byte-order fix the recent update to progress display code.

* sg/progress-fix:
  test-progress: fix test failures on big-endian systems
2019-10-23 14:43:09 +09:00
Junio C Hamano
b895e8dea6 Merge branch 'nr/diff-highlight-indent-fix'
Code cleanup.

* nr/diff-highlight-indent-fix:
  diff-highlight: fix a whitespace nit
2019-10-23 14:43:09 +09:00
Junio C Hamano
c1ec35dd48 Merge branch 'mb/clarify-zsh-completion-doc'
The installation instruction for zsh completion script (in
contrib/) has been a bit improved.

* mb/clarify-zsh-completion-doc:
  completion: clarify installation instruction for zsh
2019-10-23 14:43:09 +09:00
SZEDER Gábor
f45f88b2e4 path.c: don't call the match function without value in trie_find()
'logs/refs' is not a working tree-specific path, but since commit
b9317d55a3 (Make sure refs/rewritten/ is per-worktree, 2019-03-07)
'git rev-parse --git-path' has been returning a bogus path if a
trailing '/' is present:

  $ git -C WT/ rev-parse --git-path logs/refs --git-path logs/refs/
  /home/szeder/src/git/.git/logs/refs
  /home/szeder/src/git/.git/worktrees/WT/logs/refs/

We use a trie data structure to efficiently decide whether a path
belongs to the common dir or is working tree-specific.  As it happens
b9317d55a3 triggered a bug that is as old as the trie implementation
itself, added in 4e09cf2acf (path: optimize common dir checking,
2015-08-31).

  - According to the comment describing trie_find(), it should only
    call the given match function 'fn' for a "/-or-\0-terminated
    prefix of the key for which the trie contains a value".  This is
    not true: there are three places where trie_find() calls the match
    function, but one of them is missing the check for value's
    existence.

  - b9317d55a3 added two new keys to the trie: 'logs/refs/rewritten'
    and 'logs/refs/worktree', next to the already existing
    'logs/refs/bisect'.  This resulted in a trie node with the path
    'logs/refs/', which didn't exist before, and which doesn't have a
    value attached.  A query for 'logs/refs/' finds this node and then
    hits that one callsite of the match function which doesn't check
    for the value's existence, and thus invokes the match function
    with NULL as value.

  - When the match function check_common() is invoked with a NULL
    value, it returns 0, which indicates that the queried path doesn't
    belong to the common directory, ultimately resulting the bogus
    path shown above.

Add the missing condition to trie_find() so it will never invoke the
match function with a non-existing value.  check_common() will then no
longer have to check that it got a non-NULL value, so remove that
condition.

I believe that there are no other paths that could cause similar bogus
output.  AFAICT the only other key resulting in the match function
being called with a NULL value is 'co' (because of the keys 'common'
and 'config').  However, as they are not in a directory that belongs
to the common directory the resulting working tree-specific path is
expected.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:54:22 +09:00
SZEDER Gábor
c72fc40d09 path.c: clarify two field names in 'struct common_dir'
An array of 'struct common_dir' instances is used to specify whether
various paths in $GIT_DIR are specific to a worktree, or are common,
i.e. belong to main worktree.  The names of two fields in this
struct are somewhat confusing or ambigious:

  - The path is recorded in the struct's 'dirname' field, even though
    several entries are regular files e.g. 'gc.pid', 'packed-refs',
    etc.

    Rename this field to 'path' to reduce confusion.

  - The field 'exclude' tells whether the path is excluded...  from
    where?  Excluded from the common dir or from the worktree?  It
    means the former, but it's ambigious.

    Rename this field to 'is_common' to make it unambigious what it
    means.  This, however, means the exact opposite of what 'exclude'
    meant, so we have to negate the field's value in all entries as
    well.

The diff is best viewed with '--color-words'.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:53:51 +09:00
SZEDER Gábor
8a64881b44 path.c: mark 'logs/HEAD' in 'common_list' as file
'logs/HEAD', i.e. HEAD's reflog, is a file, but its entry in
'common_list' has the 'is_dir' bit set.

Unset that bit to make it consistent with what 'logs/HEAD' is supposed
to be.

This doesn't make a difference in behavior: check_common() is the only
function that looks at the 'is_dir' bit, and that function either
returns 0, or '!exclude', which for 'logs/HEAD' results in 0 as well.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:53:51 +09:00
SZEDER Gábor
7cb8c929d7 path.c: clarify trie_find()'s in-code comment
A fairly long comment describes trie_find()'s behavior and shows
examples, but it's slightly incomplete/inaccurate.  Update this
comment to specify how trie_find() handles a negative return value
from the given match function.

Furthermore, update the list of examples to include not only two but
three levels of path components.  This makes the examples slightly
more complicated, but it can illustrate the behavior in more corner
cases.

Finally, basically everything refers to the data stored for a key as
"value", with two confusing exceptions:

  - The type definition of the match function calls its corresponding
    parameter 'data'.
    Rename that parameter to 'value'.  (check_common(), the only
    function of this type already calls it 'value').

  - The table of examples above trie_find() has a "val from node"
    column, which has nothing to do with the value stored in the trie:
    it's a "prefix of the key for which the trie contains a value"
    that led to that node.
    Rename that column header to "prefix to node".

Note that neither the original nor the updated description and
examples correspond 100% to the current implementation, because the
implementation is a bit buggy, but the comment describes the desired
behavior.  The bug will be fixed in the last patch of this series.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:53:51 +09:00
SZEDER Gábor
e536b1fedf Documentation: mention more worktree-specific exceptions
If a directory in $GIT_DIR is overridden when $GIT_COMMON_DIR is set,
then usually all paths within that directory are overridden as well.
There are a couple of exceptions, though, and two of them, namely
'refs/rewritten' and 'logs/HEAD' are not mentioned in
'gitrepository-layout'.  Document them as well.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:53:50 +09:00
William Baker
680cba2c2b multi-pack-index: add [--[no-]progress] option.
Add the --[no-]progress option to git multi-pack-index.
Pass the MIDX_PROGRESS flag to the subcommand functions
when progress should be displayed by multi-pack-index.
The progress feature was added to 'verify' in 144d703
("multi-pack-index: report progress during 'verify'", 2018-09-13)
but some subcommands were not updated to display progress, and
the ability to opt-out was overlooked.

Signed-off-by: William Baker <William.Baker@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:05:06 +09:00
William Baker
64d80e7d52 midx: honor the MIDX_PROGRESS flag in midx_repack
Update midx_repack to only display progress when
the MIDX_PROGRESS flag is set.

Signed-off-by: William Baker <William.Baker@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:05:06 +09:00
William Baker
ad60096d1c midx: honor the MIDX_PROGRESS flag in verify_midx_file
Update verify_midx_file to only display progress when
the MIDX_PROGRESS flag is set.

Signed-off-by: William Baker <William.Baker@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:05:05 +09:00
William Baker
8dc18f8937 midx: add progress to expire_midx_packs
Add progress to expire_midx_packs.  Progress is
displayed when the MIDX_PROGRESS flag is set.

Signed-off-by: William Baker <William.Baker@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:05:05 +09:00
William Baker
840cef0c70 midx: add progress to write_midx_file
Add progress to write_midx_file.  Progress is displayed
when the MIDX_PROGRESS flag is set.

Signed-off-by: William Baker <William.Baker@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:05:05 +09:00
William Baker
efbc3aee08 midx: add MIDX_PROGRESS flag
Add the MIDX_PROGRESS flag and update the
write|verify|expire|repack functions in midx.h
to accept a flags parameter.  The MIDX_PROGRESS
flag indicates whether the caller of the function
would like progress information to be displayed.
This patch only changes the method prototypes
and does not change the functionality. The
functionality change will be handled by a later patch.

Signed-off-by: William Baker <William.Baker@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 12:05:05 +09:00
Johannes Schindelin
0eb3671ed9 ci(osx): use new location of the perforce cask
The Azure Pipelines builds are failing for macOS due to a change in the
location of the perforce cask. The command outputs the following error:

    + brew install caskroom/cask/perforce
    Error: caskroom/cask was moved. Tap homebrew/cask-cask instead.

So let's try to call `brew cask install perforce` first (which is what
that error message suggests, in a most round-about way).

Prior to 672f51cb we used to install the 'perforce' package with 'brew
install perforce' (note: no 'cask' in there). The justification for
672f51cb was that the command 'brew install perforce' simply stopped
working, after Homebrew folks decided that it's better to move the
'perforce' package to a "cask". Their justification for this move was
that 'brew install perforce' "can fail due to a checksum mismatch ...",
and casks can be installed without checksum verification. And indeed,
both 'brew cask install perforce' and 'brew install
caskroom/cask/perforce' printed something along the lines of:

  ==> No checksum defined for Cask perforce, skipping verification

It is unclear why 672f51cb used 'brew install caskroom/cask/perforce'
instead of 'brew cask install perforce'. It appears (by running both
commands on old Travis CI macOS images) that both commands worked all
the same already back then.

In any case, as the error message at the top of this commit message
shows, 'brew install caskroom/cask/perforce' has stopped working
recently, but 'brew cask install perforce' still does, so let's use
that.

CI servers are typically fresh virtual machines, but not always. To
accommodate for that, let's try harder if `brew cask install perforce`
fails, by specifically pulling the latest `master` of the
`homebrew-cask` repository.

This will still fail, of course, when `homebrew-cask` falls behind
Perforce's release schedule. But once it is updated, we can now simply
re-run the failed jobs and they will pick up that update.

As for updating `homebrew-cask`: the beginnings of automating this in
https://dev.azure.com/gitgitgadget/git/_build?definitionId=11&_a=summary
will be finished once the next Perforce upgrade comes around.

Helped-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 11:46:41 +09:00
Elijah Newren
da1e295e00 t604[236]: do not run setup in separate tests
Transform the setup "tests" to setup functions, and have the actual
tests call the setup functions.  Advantages:

  * Should make life easier for people working with webby CI/PR builds
    who have to abuse mice (and their own index finger as well) in
    order to switch from viewing one testcase to another.  Sounds
    awful; hopefully this will improve things for them.

  * Improves re-runnability: any failed test in any of these three
    files can now be re-run in isolation, e.g.
       ./t6042* --ver --imm -x --run=21
    whereas before it would require two tests to be specified to the
    --run argument, the other needing to be picked out as the relevant
    setup test from one or two tests before.

  * Importantly, this still keeps the "setup" and "test" sections
    somewhat separate to make it easier for readers to discern what is
    just ancillary setup and what the intent of the test is.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 11:32:51 +09:00
Elijah Newren
49b8133a9e merge-recursive: fix merging a subdirectory into the root directory
We allow renaming all entries in e.g. a directory named z/ into a
directory named y/ to be detected as a z/ -> y/ rename, so that if the
other side of history adds any files to the directory z/ in the mean
time, we can provide the hint that they should be moved to y/.

There is no reason to not allow 'y/' to be the root directory, but the
code did not handle that case correctly.  Add a testcase and the
necessary special checks to support this case.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 11:32:49 +09:00
Elijah Newren
d3eebaad5e merge-recursive: clean up get_renamed_dir_portion()
Dscho noted a few things making this function hard to follow.
Restructure it a bit and add comments to make it easier to follow.  The
restructurings include:

  * There was a special case if-check at the end of the function
    checking whether someone just renamed a file within its original
    directory, meaning that there could be no directory rename involved.
    That check was slightly convoluted; it could be done in a more
    straightforward fashion earlier in the function, and can be done
    more cheaply too (no call to strncmp).

  * The conditions for advancing end_of_old and end_of_new before
    calling strchr were both confusing and unnecessary.  If either
    points at a '/', then they need to be advanced in order to find the
    next '/'.  If either doesn't point at a '/', then advancing them one
    char before calling strchr() doesn't hurt.  So, just rip out the
    if conditions and advance both before calling strchr().

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 11:32:48 +09:00
Junio C Hamano
80736d7c5e doc: am --show-current-patch gives an entire e-mail message
The existing wording gives an impression that it only gives the
contents of the $GIT_DIR/rebase-apply/patch file, i.e. the patch
proper, but the option actually emits the entire e-mail message
being processed (iow, one of the output files from "git mailsplit").

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 11:26:37 +09:00
Denton Liu
a8e2c0eadc t7419: change test_must_fail to ! for grep
According to t/README, test_must_fail() should only be used to test for
failure in Git commands. Replace the invocations of
`test_must_fail grep` with `! grep`.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 11:18:28 +09:00
Bert Wesarg
19c29e538e t4014: make output-directory tests self-contained
As noted by Gábor in [1], the new tests in edefc31873 ("format-patch:
create leading components of output directory", 2019-10-11) cannot be
run independently. Fix this.

[1] https://public-inbox.org/git/20191011144650.GM29845@szeder.dev/

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 11:08:58 +09:00
Junio C Hamano
12a4aeaad8 Merge branch 'js/azure-pipelines-msvc'
* js/azure-pipelines-msvc:
  ci(visual-studio): actually run the tests in parallel
  ci(visual-studio): use strict compile flags, and optimization
2019-10-23 11:06:46 +09:00
Johannes Schindelin
399c23c046 ci(visual-studio): actually run the tests in parallel
Originally, the CI/PR builds that build and test using Visual Studio
were implemented imitating `linux-clang`, i.e. still using the
`Makefile`-based build infrastructure.

Later (but still before the patches made their way into git.git's
`master`), however, this was changed to generate Visual Studio project
files and build the binaries using `MSBuild`, as this reflects more
accurately how Visual Studio users would want to build Git (internally,
Visual Studio uses `MSBuild`, or at least something very similar).

During that transition, we needed to implement a new way to run the test
suite in parallel, as Visual Studio users typically will only have a Git
Bash available (which does not ship with `make` nor with support for
`prove`): we simply implemented a new test helper to run the test suite.

This helper even knows how to run the tests in parallel, but due to a
mistake on this developer's part, it was never turned on in the CI/PR
builds. This results in 2x-3x longer run times of the test phase.

Let's use the `--jobs=10` option to fix this.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 11:02:59 +09:00
Johannes Schindelin
711cd6d15c ci(visual-studio): use strict compile flags, and optimization
To make full use of the work that went into the Visual Studio build &
test jobs in our CI/PR builds, let's turn on strict compiler flags. This
will give us the benefit of Visual C's compiler warnings (which, at
times, seem to catch things that GCC does not catch, and vice versa).

While at it, also turn on optimization; It does not make sense to
produce binaries with debug information, and we can use any ounce of
speed that we get (because the test suite is particularly slow on
Windows, thanks to the need to run inside a Unix shell, which
requires us to use the POSIX emulation layer provided by MSYS2).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23 11:02:57 +09:00
Alessandro Menti
370784e0e6
l10n: it.po: update the Italian translation for Git 2.24.0
Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>
2019-10-22 20:05:10 +02:00
Jiang Xin
cc73c68603 Merge branch 'master' of github.com:jnavila/git into git-po-master
* 'master' of github.com:jnavila/git:
  l10n: fr 2.24.0 rnd 1
2019-10-22 09:47:23 +08:00
Jiang Xin
907843be3b Merge branch 'master' of github.com:alshopov/git-po into git-po-master
* 'master' of github.com:alshopov/git-po:
  l10n: bg.po: Updated Bulgarian translation (4693)
2019-10-22 09:16:24 +08:00
Jean-Noël Avila
13bcea8c7f l10n: fr 2.24.0 rnd 1
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2019-10-21 20:49:16 +02:00
Jiang Xin
135480a616 Merge remote-tracking branch 'git-po/master' into git-po-master
* git-po/master:
  l10n: sv.po: Update Swedish translation (4674t0f0u)
  l10n: Update Catalan translation
2019-10-21 19:57:27 +08:00
Jiang Xin
3d0a05b464 l10n: git.pot: v2.24.0 round 1 (35 new, 16 removed)
Generate po/git.pot from v2.24.0-rc0 for git v2.24.0 l10n round 1.

Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
2019-10-21 19:56:08 +08:00
Stephen Boyd
8da56a4848 userdiff: fix some corner cases in dts regex
While reviewing some dts diffs recently I noticed that the hunk header
logic was failing to find the containing node. This is because the regex
doesn't consider properties that may span multiple lines, i.e.

	property = <something>,
		   <something_else>;

and it got hung up on comments inside nodes that look like the root node
because they start with '/*'. Add tests for these cases and update the
regex to find them. Maybe detecting the root node is too complicated but
forcing it to be a backslash with any amount of whitespace up to an open
bracket seemed OK. I tried to detect that a comment is in-between the
two parts but I wasn't happy so I just dropped it.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-21 17:44:12 +09:00
Hariom Verma
86795774bb builtin/blame.c: constants into bit shift format
We are looking at bitfield constants, and elsewhere in the Git source
code, such cases are handled via bit shift operators rather than octal
numbers, which also makes it easier to spot holes in the range
(if, say, 1<<5 was missing, it is easier to spot it between 1<<4
and 1<<6 than it is to spot a missing 040 between a 020 and a 0100).

Signed-off-by: Hariom Verma <hariom18599@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-21 12:45:51 +09:00
Denton Liu
feebd2d256 rebase: hide --preserve-merges option
Since --preserve-merges has been deprecated in favour of
--rebase-merges, mark this option as hidden so it no longer shows up in
the usage and completions.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-21 12:03:49 +09:00
SZEDER Gábor
2b6f6ea1bd test-progress: fix test failures on big-endian systems
In 't0500-progress-display.sh' all tests running 'test-tool progress
--total=<N>' fail on big-endian systems, e.g. like this:

  + test-tool progress --total=3 Working hard
  [...]
  + test_i18ncmp expect out
  --- expect	2019-10-18 23:07:54.765523916 +0000
  +++ out	2019-10-18 23:07:54.773523916 +0000
  @@ -1,4 +1,2 @@
  -Working hard:  33% (1/3)<CR>
  -Working hard:  66% (2/3)<CR>
  -Working hard: 100% (3/3)<CR>
  -Working hard: 100% (3/3), done.
  +Working hard:   0% (1/12884901888)<CR>
  +Working hard:   0% (3/12884901888), done.

The reason for that bogus value is that '--total's parameter is parsed
via parse-options's OPT_INTEGER into a uint64_t variable [1], so the
two bits of 3 end up in the "wrong" bytes on big-endian systems
(12884901888 = 0x300000000).

Change the type of that variable from uint64_t to int, to match what
parse-options expects; in the tests of the progress output we won't
use values that don't fit into an int anyway.

[1] start_progress() expects the total number as an uint64_t, that's
    why I chose the same type when declaring the variable holding the
    value given on the command line.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
[jpag: Debian unstable/ppc64 (big-endian)]
Tested-By: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
[tz: Fedora s390x (big-endian)]
Tested-By: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-21 09:53:49 +09:00
Alexander Shopov
f757409e36 l10n: bg.po: Updated Bulgarian translation (4693)
Synced with 2.24-rc0

Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2019-10-19 12:20:43 +02:00
Maxim Belsky
176f5adfdb completion: clarify installation instruction for zsh
The original comment does not describe type of ~/.zsh/_git explicitly
and zsh does not warn or fail if a user create it as a dictionary.
So unexperienced users could be misled by the original comment.

There is a small update to clarify it.

Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Maxim Belsky <public.belsky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18 13:55:49 +09:00
Junio C Hamano
d966095db0 Git 2.24-rc0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18 11:40:50 +09:00
Junio C Hamano
90e0d167c6 Merge branch 'rs/remote-curl-use-argv-array'
Code cleanup.

* rs/remote-curl-use-argv-array:
  remote-curl: use argv_array in parse_push()
2019-10-18 11:40:50 +09:00
Junio C Hamano
3def8ae9a4 Merge branch 'rs/column-use-utf8-strnwidth'
Code cleanup.

* rs/column-use-utf8-strnwidth:
  column: use utf8_strnwidth() to strip out ANSI color escapes
2019-10-18 11:40:49 +09:00
Junio C Hamano
d0258d0944 Merge branch 'rs/http-push-simplify'
Code cleanup.

* rs/http-push-simplify:
  http-push: simplify deleting a list item
2019-10-18 11:40:49 +09:00
Junio C Hamano
bb52def6da Merge branch 'jj/stash-reset-only-toplevel'
"git stash save" lost local changes to submodules, which has been
corrected.

* jj/stash-reset-only-toplevel:
  stash: avoid recursive hard reset on submodules
2019-10-18 11:40:49 +09:00
Junio C Hamano
f1afbb063f Merge branch 'bw/format-patch-o-create-leading-dirs'
"git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>"
not "mkdir -p <outdir>", which is being corrected.

* bw/format-patch-o-create-leading-dirs:
  format-patch: create leading components of output directory
2019-10-18 11:40:48 +09:00
Junio C Hamano
e5fca6b573 Merge branch 'bb/compat-util-comment-fix'
Code cleanup.

* bb/compat-util-comment-fix:
  git-compat-util: fix documentation syntax
2019-10-18 11:40:48 +09:00
Junio C Hamano
43400b4222 Merge branch 'bb/utf8-wcwidth-cleanup'
Code cleanup.

* bb/utf8-wcwidth-cleanup:
  utf8: use ARRAY_SIZE() in git_wcwidth()
2019-10-18 11:40:48 +09:00