| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
l10n-2.34.0-rnd3.1
* tag 'l10n-2.34.0-rnd3.1' of git://github.com/git-l10n/git-po: (38 commits)
l10n: pl: 2.34.0 round 3
l10n: it: fix typos found by git-po-helper
l10n: ko: fix typos found by git-po-helper
l10n: Update Catalan translation
l10n: po-id for 2.34 (round 3)
l10n: bg.po: Updated Bulgarian translation (5211t)
l10n: de.po: Update German translation for Git v2.34.0
l10n: sv.po: Update Swedish translation (5211t0f0)
l10n: vi(5211t): Translation for v2.34.0 rd3
l10n: zh_TW.po: v2.34.0 round 3 (0 untranslated)
l10n: fr: v2.34.0 rnd 3
l10n: tr: v2.34.0 round 3
l10n: zh_CN: v2.34.0 round 3
l10n: git.pot: v2.34.0 round 3 (1 new)
l10n: pl: 2.34.0 round 2
l10n: vi(5210t): Translation for v2.34.0 rd2
l10n: es: 2.34.0 round 2
l10n: Update Catalan translation
l10n: bg.po: Updated Bulgarian translation (5210t)
l10n: fr: v2.34.0 round 2
...
|
|
Signed-off-by: Arusekk <arek_koz@o2.pl>
|
|
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
|
|
When checking typos in file "po/ko.po", "git-po-helper" reports lots of
false positives because there are no spaces between ASCII and Korean
characters. After applied commit adee197 "(dict: add smudge table for
Korean language, 2021-11-11)" of "git-l10n/git-po-helper" to suppress
these false positives, some easy-to-fix typos are found and fixed.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
|
|
Signed-off-by: Jordi Mas <jmas@softcatala.org>
|
|
* 'po-id' of github.com:bagasme/git-po:
l10n: po-id for 2.34 (round 3)
|
|
- Translate following new components:
* merge.c
* rebase-interactive.c
* rebase.c
* midx.c
- Clean up obsolete translations
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
|
|
* 'master' of github.com:ruester/git-po-de:
l10n: de.po: Update German translation for Git v2.34.0
|
|
When we added a new event type to trace2 event stream, we forgot to
raise the format version number, which has been corrected.
* js/trace2-raise-format-version:
trace2: increment event format version
|
|
Regression fix.
* ab/fsck-unexpected-type:
object-file: free(*contents) only in read_loose_object() caller
object-file: fix SEGV on free() regression in v2.34.0-rc2
|
|
Regression fix.
* ps/connectivity-optim:
Revert "connected: do not sort input revisions"
|
|
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
|
|
Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com>
Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com>
|
|
In 64bc752 (trace2: add trace2_child_ready() to report on background
children, 2021-09-20), we added a new "child_ready" event. In
Documentation/technical/api-trace2.txt, we promise that adding a new
event type will result in incrementing the trace2 event format version
number, but this was not done. Correct this in code & docs.
Signed-off-by: Josh Steadmon <steadmon@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
|
|
In the preceding commit a free() of uninitialized memory regression in
96e41f58fe1 (fsck: report invalid object type-path combinations,
2021-10-01) was fixed, but we'd still have an issue with leaking
memory from fsck_loose(). Let's fix that issue too.
That issue was introduced in my 31deb28f5e0 (fsck: don't hard die on
invalid object types, 2021-10-01). It can be reproduced under
SANITIZE=leak with the test I added in 093fffdfbec (fsck tests: add
test for fsck-ing an unknown type, 2021-10-01):
./t1450-fsck.sh --run=84 -vixd
In some sense it's not a problem, we lost the same amount of memory in
terms of things malloc'd and not free'd. It just moved from the "still
reachable" to "definitely lost" column in valgrind(1) nomenclature[1],
since we'd have die()'d before.
But now that we don't hard die() anymore in the library let's properly
free() it. Doing so makes this code much easier to follow, since we'll
now have one function owning the freeing of the "contents" variable,
not two.
For context on that memory management pattern the read_loose_object()
function was added in f6371f92104 (sha1_file: add read_loose_object()
function, 2017-01-13) and subsequently used in c68b489e564 (fsck:
parse loose object paths directly, 2017-01-13). The pattern of it
being the task of both sides to free() the memory has been there in
this form since its inception.
1. https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
This reverts commit f45022dc2fd692fd024f2eb41a86a66f19013d43,
as this is like breakage in the traversal more likely. In a
history with 10 single strand of pearls,
1-->2-->3--...->7-->8-->9-->10
asking "rev-list --unsorted-input 1 10 --not 9 8 7 6 5 4" fails to
paint the bottom 1 uninteresting as the traversal stops, without
completing the propagation of uninteresting bit starting at 4 down
through 3 and 2 to 1.
|
|
Fix a regression introduced in my 96e41f58fe1 (fsck: report invalid
object type-path combinations, 2021-10-01). When fsck-ing blobs larger
than core.bigFileThreshold, we'd free() a pointer to uninitialized
memory.
This issue would have been caught by SANITIZE=address, but since it
involves core.bigFileThreshold, none of the existing tests in our test
suite covered it.
Running them with the "big_file_threshold" in "environment.c" changed
to say "6" would have shown this failure, but let's add a dedicated
test for this scenario based on Han Xin's report[1].
The bug was introduced between v9 and v10[2] of the fsck series merged
in 061a21d36d8 (Merge branch 'ab/fsck-unexpected-type', 2021-10-25).
1. https://lore.kernel.org/git/20211111030302.75694-1-hanxin.hx@alibaba-inc.com/
2. https://lore.kernel.org/git/cover-v10-00.17-00000000000-20211001T091051Z-avarab@gmail.com/
Reported-by: Han Xin <chiyutianyi@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
|
|
* 'l10n/zh_TW/211111' of github.com:l10n-tw/git-po:
l10n: zh_TW.po: v2.34.0 round 3 (0 untranslated)
|
|
* 'fr_v2.34.0_rnd3' of github.com:jnavila/git:
l10n: fr: v2.34.0 rnd 3
|
|
* 'tr-2-34-r3' of github.com:bitigchi/git-po:
l10n: tr: v2.34.0 round 3
|
|
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Reject OpenSSH 8.7 whose "ssh-keygen -Y find-principals" is
unusable from running the ssh signature tests.
* jk/ssh-signing-fix:
t/lib-gpg: avoid broken versions of ssh-keygen
|
|
The way Cygwin emulates a unix-domain socket, on top of which the
simple-ipc mechanism is implemented, can race with the program on
the other side that wants to use the socket, and briefly make it
appear as a regular file before lstat(2) starts reporting it as a
socket. We now have a workaround on the side that connects to a
unix domain socket.
* js/simple-ipc-cygwin-socket-fix:
simple-ipc: work around issues with Cygwin's Unix socket emulation
|
|
"git maintenance run" learned to use system supplied scheduler
backend, but cron on macOS turns out to be unusable for this
purpose.
* ds/no-usable-cron-on-macos:
maintenance: disable cron on macOS
|
|
"git pull --ff-only" and "git pull --rebase --ff-only" should make
it a no-op to attempt pulling from a remote that is behind us, but
instead the command errored out by saying it was impossible to
fast-forward, which may technically be true, but not a useful thing
to diagnose as an error. This has been corrected.
* jc/fix-pull-ff-only-when-already-up-to-date:
pull: --ff-only should make it a noop when already-up-to-date
|
|
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
|
|
The "-Y find-principals" option of ssh-keygen seems to be broken in
Debian's openssh-client 1:8.7p1-1, whereas it works fine in 1:8.4p1-5.
This causes several failures for GPGSSH tests. We fulfill the
prerequisite because generating the keys works fine, but actually
verifying a signature causes results ranging from bogus results to
ssh-keygen segfaulting.
We can find the broken version during the prereq check by feeding it
empty input. This should result in it complaining to stderr, but in the
broken version it triggers the segfault, causing the GPGSSH tests to be
skipped.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
|
|
In eba1ba9 (maintenance: `git maintenance run` learned
`--scheduler=<scheduler>`, 2021-09-04), we introduced the ability to
specify a scheduler explicitly. This led to some extra checks around
whether an alternative scheduler was available. This added the
functionality of removing background maintenance from schedulers other
than the one selected.
On macOS, cron is technically available, but running 'crontab' triggers
a UI prompt asking for special permissions. This is the major reason why
launchctl is used as the default scheduler. The is_crontab_available()
method triggers this UI prompt, causing user disruption.
Remove this disruption by using an #ifdef to prevent running crontab
this way on macOS. This has the unfortunate downside that if a user
manually selects cron via the '--scheduler' option, then adjusting the
scheduler later will not remove the schedule from cron. The
'--scheduler' option ignores the is_available checks, which is how we
can get into this situation.
Extract the new check_crontab_process() method to avoid making the
'child' variable unused on macOS. The method is marked MAYBE_UNUSED
because it has no callers on macOS.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Emir Sarı <bitigchi@me.com>
|
|
Cygwin emulates Unix sockets by writing files with custom contents and
then marking them as system files.
The tricky problem is that while the file is written and its `system`
bit is set, it is still identified as a file. This caused test failures
when Git is too fast looking for the Unix sockets and then complains
that there is a plain file in the way.
Let's work around this by adding a delayed retry loop, specifically for
Cygwin.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Fangyi Zhou <me@fangyi.io>
|
|
* 'master' of github.com:alshopov/git-po:
l10n: bg.po: Updated Bulgarian translation (5210t)
|
|
Generate po/git.pot from v2.34.0-rc2 for git v2.34.0 l10n round 3.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
|
|
* 'master' of github.com:git/git:
Git 2.34-rc2
parse-options.[ch]: revert use of "enum" for parse_options()
t/lib-git.sh: fix ACL-related permissions failure
A few fixes before -rc2
async_die_is_recursing: work around GCC v11.x issue on Fedora
Document positive variant of commit and merge option "--no-verify"
pull: honor --no-verify and do not call the commit-msg hook
http-backend: remove a duplicated code branch
|
|
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Last minute fix to the update already in 'master'.
* ab/parse-options-cleanup:
parse-options.[ch]: revert use of "enum" for parse_options()
|
|
Fix ssh-signing test to work on a platform where the default ACL is
overly loose to upset OpenSSH (reported on an installation of Cygwin).
* ad/ssh-signing-testfix:
t/lib-git.sh: fix ACL-related permissions failure
|
|
Revert the parse_options() prototype change in my recent
352e761388b (parse-options.[ch]: consistently use "enum
parse_opt_result", 2021-10-08) was incorrect. The parse_options()
function returns the number of argc elements that haven't been
processed, not "enum parse_opt_result".
Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Arusekk <arek_koz@o2.pl>
|
|
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
|
|
Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com>
Signed-off-by: Omar Olivares <omar@olivares.cl>
Signed-off-by: Jaime Marquínez Ferrándiz <jaime.marquinez.ferrandiz@fastmail.net>
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
|
|
Signed-off-by: Jordi Mas <jmas@softcatala.org>
|
|
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
|
|
* 'pt-PT' of github.com:git-l10n-pt-PT/git-po:
l10n: pt_PT: cleaning duplicate translations (#2)
|
|
* 'l10n/zh_TW/211104' of github.com:l10n-tw/git-po:
l10n: zh_TW.po: v2.34.0 round 2 (0 untranslated)
|
|
As well as checking that the relevant functionality is available, the
GPGSSH prerequisite check creates the SSH keys that are used by the test
functions it gates. If these keys are created in a directory that
has a default Access Control List, the key files can inherit those
permissions.
This can result in a scenario where the private keys are created
successfully, so the prerequisite check passes and the tests are run,
but the key files have permissions that are too permissive, meaning
OpenSSH will refuse to load them and the tests will fail.
To avoid this happening, before creating the keys, clear any default ACL
set on the directory that will contain them. This step allowed to fail;
if setfacl isn't present, that's a very likely indicator that the
filesystem in question simply doesn't support default ACLs.
Helped-by: Fabian Stelzer <fs@gigacodes.de>
Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
Junio C Hamano
Arusekk
Jiang Xin
Jordi Mas
Bagas Sanjaya
Alexander Shopov
Matthias Rüster
Josh Steadmon
Peter Krefting
Ævar Arnfjörð Bjarmason
Tran Ngoc Quan
Yi-Jyun Pan
Jeff King
Jean-Noël Avila
Derrick Stolee
Emir Sarı
Johannes Schindelin
Fangyi Zhou
Christopher Diaz Riveros
Adam Dinwoodie