summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-26t/perf/fsmonitor: add benchmark for dirty statusLibravatar Nipunn Koorapati1-0/+5
This benchmark covers the git status time for a heavily dirty directory - benchmarking fsmonitor's refresh When running to compare our perl vs rs-git-fsmonitor - we see that the perl script incurs significant overhead - further motivation to provide a faster implementation within git. 7519.7: status (dirty) (fsmonitor=query-watchman) 10.05(7.78+1.56) 7519.20: status (dirty) (fsmonitor=rs-git-fsmonitor) 6.72(4.37+1.64) 7519.33: status (dirty) (fsmonitor=disabled) 5.62(4.24+2.03) Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/perf/fsmonitor: perf comparison of multiple fsmonitor integrationsLibravatar Nipunn Koorapati1-8/+14
Allows for simple perf comparison of different integrations. I ran it to compare our perl script w/ rs-git-fsmonitor and found 20-30ms of overhead on every command. Output looks like this (extra newlines added for readability) Test this tree --------------------------------------------------------------------------- 7519.4: status (fsmonitor=query-watchman) 0.42(0.37+0.05) 7519.5: status -uno (fsmonitor=query-watchman) 0.19(0.12+0.07) 7519.6: status -uall (fsmonitor=query-watchman) 1.36(0.73+0.62) 7519.7: diff (fsmonitor=query-watchman) 0.14(0.09+0.05) 7519.8: diff -- 0_files (fsmonitor=query-watchman) 0.14(0.11+0.03) 7519.9: diff -- 10_files (fsmonitor=query-watchman) 0.14(0.10+0.04) 7519.10: diff -- 100_files (fsmonitor=query-watchman) 0.14(0.09+0.05) 7519.11: diff -- 1000_files (fsmonitor=query-watchman) 0.14(0.08+0.06) 7519.12: diff -- 10000_files (fsmonitor=query-watchman) 0.14(0.09+0.05) 7519.13: add (fsmonitor=query-watchman) 2.04(1.32+0.66) 7519.16: status (fsmonitor=rs-git-fsmonitor) 0.39(0.32+0.08) 7519.17: status -uno (fsmonitor=rs-git-fsmonitor) 0.17(0.11+0.06) 7519.18: status -uall (fsmonitor=rs-git-fsmonitor) 1.33(0.71+0.61) 7519.19: diff (fsmonitor=rs-git-fsmonitor) 0.11(0.07+0.04) 7519.20: diff -- 0_files (fsmonitor=rs-git-fsmonitor) 0.11(0.09+0.03) 7519.21: diff -- 10_files (fsmonitor=rs-git-fsmonitor) 0.11(0.09+0.03) 7519.22: diff -- 100_files (fsmonitor=rs-git-fsmonitor) 0.11(0.07+0.04) 7519.23: diff -- 1000_files (fsmonitor=rs-git-fsmonitor) 0.11(0.06+0.06) 7519.24: diff -- 10000_files (fsmonitor=rs-git-fsmonitor) 0.11(0.06+0.06) 7519.25: add (fsmonitor=rs-git-fsmonitor) 2.03(1.28+0.69) 7519.28: status (fsmonitor=disabled) 0.77(0.59+0.99) 7519.29: status -uno (fsmonitor=disabled) 0.42(0.33+0.85) 7519.30: status -uall (fsmonitor=disabled) 1.59(1.02+1.34) 7519.31: diff (fsmonitor=disabled) 0.35(0.30+0.81) 7519.32: diff -- 0_files (fsmonitor=disabled) 0.11(0.08+0.04) 7519.33: diff -- 10_files (fsmonitor=disabled) 0.11(0.07+0.04) 7519.34: diff -- 100_files (fsmonitor=disabled) 0.11(0.08+0.03) 7519.35: diff -- 1000_files (fsmonitor=disabled) 0.11(0.10+0.02) 7519.36: diff -- 10000_files (fsmonitor=disabled) 0.12(0.07+0.06) 7519.37: add (fsmonitor=disabled) 2.24(1.48+1.44) Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/perf/fsmonitor: initialize test with git resetLibravatar Nipunn Koorapati1-2/+6
Previously, the git add of the previous suiterun would pollute the numbers in the second run Before: Test this tree ----------------------------------------------------------------------------- 7519.4: status (fsmonitor=fsmonitor-watchman) 0.40(0.36+0.04) 7519.5: status -uno (fsmonitor=fsmonitor-watchman) 0.19(0.12+0.07) 7519.6: status -uall (fsmonitor=fsmonitor-watchman) 1.36(0.74+0.61) 7519.7: diff (fsmonitor=fsmonitor-watchman) 0.14(0.10+0.04) 7519.8: diff -- 0_files (fsmonitor=fsmonitor-watchman) 0.14(0.10+0.04) 7519.9: diff -- 10_files (fsmonitor=fsmonitor-watchman) 0.14(0.09+0.05) 7519.10: diff -- 100_files (fsmonitor=fsmonitor-watchman) 0.14(0.10+0.04) 7519.11: diff -- 1000_files (fsmonitor=fsmonitor-watchman) 0.14(0.08+0.06) 7519.12: diff -- 10000_files (fsmonitor=fsmonitor-watchman) 0.14(0.10+0.04) 7519.13: add (fsmonitor=fsmonitor-watchman) 2.03(1.28+0.69) 7519.16: status (fsmonitor=disabled) 0.64(0.49+0.90) 7519.17: status -uno (fsmonitor=disabled) 1.15(0.92+1.00) 7519.18: status -uall (fsmonitor=disabled) 2.32(1.46+1.55) 7519.19: diff (fsmonitor=disabled) 1.44(1.12+1.76) 7519.20: diff -- 0_files (fsmonitor=disabled) 0.11(0.07+0.05) 7519.21: diff -- 10_files (fsmonitor=disabled) 0.11(0.06+0.05) 7519.22: diff -- 100_files (fsmonitor=disabled) 0.11(0.08+0.03) 7519.23: diff -- 1000_files (fsmonitor=disabled) 0.11(0.08+0.04) 7519.24: diff -- 10000_files (fsmonitor=disabled) 0.12(0.06+0.07) 7519.25: add (fsmonitor=disabled) 2.25(1.47+1.47) After: Test this tree ----------------------------------------------------------------------------- 7519.4: status (fsmonitor=fsmonitor-watchman) 0.41(0.33+0.09) 7519.5: status -uno (fsmonitor=fsmonitor-watchman) 0.20(0.14+0.07) 7519.6: status -uall (fsmonitor=fsmonitor-watchman) 1.37(0.78+0.58) 7519.7: diff (fsmonitor=fsmonitor-watchman) 0.14(0.10+0.04) 7519.8: diff -- 0_files (fsmonitor=fsmonitor-watchman) 0.14(0.08+0.06) 7519.9: diff -- 10_files (fsmonitor=fsmonitor-watchman) 0.14(0.09+0.05) 7519.10: diff -- 100_files (fsmonitor=fsmonitor-watchman) 0.14(0.10+0.05) 7519.11: diff -- 1000_files (fsmonitor=fsmonitor-watchman) 0.14(0.11+0.04) 7519.12: diff -- 10000_files (fsmonitor=fsmonitor-watchman) 0.14(0.09+0.05) 7519.13: add (fsmonitor=fsmonitor-watchman) 2.04(1.27+0.71) 7519.16: status (fsmonitor=disabled) 0.78(0.59+0.99) 7519.17: status -uno (fsmonitor=disabled) 0.43(0.32+0.88) 7519.18: status -uall (fsmonitor=disabled) 1.58(0.96+1.38) 7519.19: diff (fsmonitor=disabled) 0.36(0.31+0.79) 7519.20: diff -- 0_files (fsmonitor=disabled) 0.11(0.08+0.03) 7519.21: diff -- 10_files (fsmonitor=disabled) 0.11(0.07+0.04) 7519.22: diff -- 100_files (fsmonitor=disabled) 0.11(0.08+0.04) 7519.23: diff -- 1000_files (fsmonitor=disabled) 0.11(0.07+0.05) 7519.24: diff -- 10000_files (fsmonitor=disabled) 0.12(0.08+0.05) 7519.25: add (fsmonitor=disabled) 2.25(1.48+1.47) Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/perf/fsmonitor: factor setup for fsmonitor into functionLibravatar Nipunn Koorapati1-2/+6
This prepares for it being called multiple times when testing different hooks Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/perf/fsmonitor: silence initial git commitLibravatar Nipunn Koorapati1-1/+1
It is extremely verbose, printing >10K non-useful lines Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/perf/fsmonitor: shorten DESC to basenameLibravatar Nipunn Koorapati1-1/+5
The full name is lengthy and makes it hard to read Before: 7519.3: status (fsmonitor=/home/nipunn/src/server/.git/hooks/rs-git-fsmonitor) 0.02(0.01+0.00) After 7519.3: status (fsmonitor=rs-git-fsmonitor) 0.03(0.02+0.00) Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/perf/fsmonitor: factor description out for readabilityLibravatar Nipunn Koorapati1-10/+12
There was much duplication here. Prepares for making changes to the description. Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/perf/fsmonitor: improve error message if typoing hook nameLibravatar Nipunn Koorapati1-1/+3
Previously - it would silently run the perf suite w/o using fsmonitor - fsmonitor errors are not hard failures. Now it errors loudly. GIT_PERF_7519_FSMONITOR="$HOME/rs-git-fsmonitorr" ./p7519-fsmonitor.sh -i -v fatal: cannot run /home/nipunn/rs-git-fsmonitorr: No such file or directory not ok 2 - setup for fsmonitor Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/perf/fsmonitor: move watchman setup to one-time-repo-setupLibravatar Nipunn Koorapati1-7/+9
It is only required to be set up once. This prepares for testing multiple hooks in one invocation. Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/perf/fsmonitor: separate one time repo initializationLibravatar Nipunn Koorapati1-8/+11
In preparation for testing multiple fsmonitor hooks Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20p7519-fsmonitor: add a git add benchmarkLibravatar Nipunn Koorapati1-0/+4
Test v2.29.0-rc1 this tree ----------------------------------------------------------------------------------------------------------------- 7519.2: status (fsmonitor=.git/hooks/fsmonitor-watchman) 1.48(0.79+0.67) 1.48(0.79+0.67) +0.0% 7519.3: status -uno (fsmonitor=.git/hooks/fsmonitor-watchman) 0.16(0.11+0.05) 0.17(0.13+0.04) +6.3% 7519.4: status -uall (fsmonitor=.git/hooks/fsmonitor-watchman) 1.36(0.77+0.58) 1.37(0.72+0.63) +0.7% 7519.5: diff (fsmonitor=.git/hooks/fsmonitor-watchman) 0.84(0.21+0.63) 0.14(0.11+0.03) -83.3% 7519.6: diff -- 0_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.12(0.07+0.05) 0.13(0.09+0.04) +8.3% 7519.7: diff -- 10_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.12(0.09+0.04) 0.13(0.07+0.06) +8.3% 7519.8: diff -- 100_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.12(0.08+0.05) 0.12(0.08+0.05) +0.0% 7519.9: diff -- 1000_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.12(0.08+0.05) 0.13(0.09+0.04) +8.3% 7519.10: diff -- 10000_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.14(0.08+0.06) 0.13(0.07+0.06) -7.1% 7519.11: add (fsmonitor=.git/hooks/fsmonitor-watchman) 2.75(1.41+1.27) 2.03(1.26+0.70) -26.2% 7519.13: status (fsmonitor=) 1.38(1.03+1.04) 1.37(1.04+1.04) -0.7% 7519.14: status -uno (fsmonitor=) 1.11(0.83+0.98) 1.10(0.89+0.90) -0.9% 7519.15: status -uall (fsmonitor=) 2.30(1.57+1.42) 2.31(1.49+1.50) +0.4% 7519.16: diff (fsmonitor=) 1.43(1.13+1.76) 1.46(1.19+1.72) +2.1% 7519.17: diff -- 0_files (fsmonitor=) 0.10(0.08+0.04) 0.11(0.08+0.04) +10.0% 7519.18: diff -- 10_files (fsmonitor=) 0.10(0.07+0.05) 0.11(0.08+0.04) +10.0% 7519.19: diff -- 100_files (fsmonitor=) 0.10(0.07+0.04) 0.11(0.07+0.05) +10.0% 7519.20: diff -- 1000_files (fsmonitor=) 0.10(0.08+0.03) 0.11(0.08+0.04) +10.0% 7519.21: diff -- 10000_files (fsmonitor=) 0.11(0.08+0.05) 0.12(0.07+0.06) +9.1% 7519.22: add (fsmonitor=) 2.26(1.46+1.49) 2.27(1.42+1.55) +0.4% Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20p7519-fsmonitor: refactor to avoid code duplicationLibravatar Nipunn Koorapati1-99/+37
Much of the benchmark code is redundant. This is easier to understand and edit. Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20perf lint: add make test-lint to perf testsLibravatar Nipunn Koorapati3-7/+11
Perf tests have not been linted for some time. They've grown some seq instead of test_seq. This runs the existing lints on the perf tests as well. Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20t/perf: add fsmonitor perf test for git diffLibravatar Nipunn Koorapati1-0/+71
Results for the git-diff fsmonitor optimization in patch in the parent-rev (using a 400k file repo to test) As you can see here - git diff with fsmonitor running is significantly better with this patch series (80% faster on my workload)! GIT_PERF_LARGE_REPO=~/src/server ./run v2.29.0-rc1 . -- p7519-fsmonitor.sh Test v2.29.0-rc1 this tree ----------------------------------------------------------------------------------------------------------------- 7519.2: status (fsmonitor=.git/hooks/fsmonitor-watchman) 1.46(0.82+0.64) 1.47(0.83+0.62) +0.7% 7519.3: status -uno (fsmonitor=.git/hooks/fsmonitor-watchman) 0.16(0.12+0.04) 0.17(0.12+0.05) +6.3% 7519.4: status -uall (fsmonitor=.git/hooks/fsmonitor-watchman) 1.36(0.73+0.62) 1.37(0.76+0.60) +0.7% 7519.5: diff (fsmonitor=.git/hooks/fsmonitor-watchman) 0.85(0.22+0.63) 0.14(0.10+0.05) -83.5% 7519.6: diff -- 0_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.12(0.08+0.05) 0.13(0.11+0.02) +8.3% 7519.7: diff -- 10_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.12(0.08+0.04) 0.13(0.09+0.04) +8.3% 7519.8: diff -- 100_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.12(0.07+0.05) 0.13(0.07+0.06) +8.3% 7519.9: diff -- 1000_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.12(0.09+0.04) 0.13(0.08+0.05) +8.3% 7519.10: diff -- 10000_files (fsmonitor=.git/hooks/fsmonitor-watchman) 0.14(0.09+0.05) 0.13(0.10+0.03) -7.1% 7519.12: status (fsmonitor=) 1.67(0.93+1.49) 1.67(0.99+1.42) +0.0% 7519.13: status -uno (fsmonitor=) 0.37(0.30+0.82) 0.37(0.33+0.79) +0.0% 7519.14: status -uall (fsmonitor=) 1.58(0.97+1.35) 1.57(0.86+1.45) -0.6% 7519.15: diff (fsmonitor=) 0.34(0.28+0.83) 0.34(0.27+0.83) +0.0% 7519.16: diff -- 0_files (fsmonitor=) 0.09(0.06+0.04) 0.09(0.08+0.02) +0.0% 7519.17: diff -- 10_files (fsmonitor=) 0.09(0.07+0.03) 0.09(0.06+0.05) +0.0% 7519.18: diff -- 100_files (fsmonitor=) 0.09(0.06+0.04) 0.09(0.06+0.04) +0.0% 7519.19: diff -- 1000_files (fsmonitor=) 0.09(0.06+0.04) 0.09(0.05+0.05) +0.0% 7519.20: diff -- 10000_files (fsmonitor=) 0.10(0.08+0.04) 0.10(0.06+0.05) +0.0% I also added a benchmark for a tiny git diff workload w/ a pathspec. I see an approximately .02 second overhead added w/ and w/o fsmonitor From looking at these results, I suspected that refresh_fsmonitor is already happening during git diff - independent of this patch series' optimization. Confirmed that suspicion by breaking on refresh_fsmonitor. (gdb) bt [simplified] 0 refresh_fsmonitor at fsmonitor.c:176 1 ie_match_stat at read-cache.c:375 2 match_stat_with_submodule at diff-lib.c:237 4 builtin_diff_files at builtin/diff.c:260 5 cmd_diff at builtin/diff.c:541 6 run_builtin at git.c:450 7 handle_builtin at git.c:700 8 run_argv at git.c:767 9 cmd_main at git.c:898 10 main at common-main.c:52 Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20t/perf/p7519-fsmonitor.sh: warm cache on first git statusLibravatar Nipunn Koorapati1-1/+2
The first git status would be inflated due to warming of filesystem cache. This makes the results comparable. Before Test this tree -------------------------------------------------------------------------------- 7519.2: status (fsmonitor=.git/hooks/fsmonitor-watchman) 2.52(1.59+1.56) 7519.3: status -uno (fsmonitor=.git/hooks/fsmonitor-watchman) 0.18(0.12+0.06) 7519.4: status -uall (fsmonitor=.git/hooks/fsmonitor-watchman) 1.36(0.73+0.62) 7519.7: status (fsmonitor=) 0.69(0.52+0.90) 7519.8: status -uno (fsmonitor=) 0.37(0.28+0.81) 7519.9: status -uall (fsmonitor=) 1.53(0.93+1.32) After Test this tree -------------------------------------------------------------------------------- 7519.2: status (fsmonitor=.git/hooks/fsmonitor-watchman) 0.39(0.33+0.06) 7519.3: status -uno (fsmonitor=.git/hooks/fsmonitor-watchman) 0.17(0.13+0.05) 7519.4: status -uall (fsmonitor=.git/hooks/fsmonitor-watchman) 1.34(0.77+0.56) 7519.7: status (fsmonitor=) 0.70(0.53+0.90) 7519.8: status -uno (fsmonitor=) 0.37(0.32+0.78) 7519.9: status -uall (fsmonitor=) 1.55(1.01+1.25) Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20t/perf/README: elaborate on output formatLibravatar Nipunn Koorapati1-0/+2
Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-20fsmonitor: use fsmonitor data in `git diff`Libravatar Alex Vandiver1-2/+13
With fsmonitor enabled, the first call to match_stat_with_submodule calls refresh_fsmonitor, incurring the overhead of reading the list of updated files -- but run_diff_files does not respect the CE_FSMONITOR_VALID flag. Make use of the fsmonitor extension to skip lstat() calls on files that fsmonitor judged as unmodified. Notably, this change improves performance of the git shell prompt when GIT_PS1_SHOWDIRTYSTATE is set. Signed-off-by: Alex Vandiver <alexmv@dropbox.com> Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-17Merge https://github.com/prati0100/git-guiLibravatar Junio C Hamano3-49/+93
* https://github.com/prati0100/git-gui: git-gui: blame: prevent tool tips from sticking around after Command-Tab git-gui: improve dark mode support git-gui: fix mixed tabs and spaces; prefer tabs
2020-10-17Merge branch 'sh/blame-tooltip'Libravatar Pratyush Yadav1-0/+1
Make sure `git gui blame` tooltips are destroyed once the window loses focus on MacOS. * sh/blame-tooltip: git-gui: blame: prevent tool tips from sticking around after Command-Tab
2020-10-17git-gui: blame: prevent tool tips from sticking around after Command-TabLibravatar Stefan Haller1-0/+1
On Mac, tooltips are not automatically removed when a window loses focus. Furthermore, mouse-move events are only dispatched to the active window, which means that if we Command-tab to another application while a tool tip is showing, the tool tip will stay there forever (in front of other applications). So we must hide it manually when we lose focus. Do this unconditionally here (i.e. without if {[is_MacOSX]}); it shouldn't hurt on other platforms, even though they don't seem to have this problem. Signed-off-by: Stefan Haller <stefan@haller-berlin.de> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2020-10-15Git 2.29-rc2Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08Git 2.29-rc1Libravatar Junio C Hamano2-14/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08Merge branch 'js/default-branch-name-part-3'Libravatar Junio C Hamano5-25/+25
Test preparation for the switch of default branch name continues. * js/default-branch-name-part-3: tests: avoid using the branch name `main` t1415: avoid using `main` as ref name
2020-10-08Merge branch 'js/ci-ghwf-dedup-tests'Libravatar Junio C Hamano2-1/+40
The logic to skip testing on the tagged commit and the tag itself was not quite consistent which led to failure of Windows test tasks. It has been revamped to consistently skip revisions that have already been tested, based on the tree object of the revision. * js/ci-ghwf-dedup-tests: ci: do not skip tagged revisions in GitHub workflows ci: skip GitHub workflow runs for already-tested commits/trees
2020-10-08Merge branch 'ja/misc-doc-fixes'Libravatar Junio C Hamano5-21/+21
Doc fixes. * ja/misc-doc-fixes: doc: fix the bnf like style of some commands doc: git-remote fix ups doc: use linkgit macro where needed. git-bisect-lk2009: make continuation of list indented
2020-10-08Merge branch 'dl/makefile-sort'Libravatar Junio C Hamano1-5/+5
Makefile clean-up. * dl/makefile-sort: Makefile: ASCII-sort += lists
2020-10-08Merge branch 'js/no-builtins-on-disk-option'Libravatar Junio C Hamano3-0/+22
Hotfix to breakage introduced in the topic in v2.29-rc0 * js/no-builtins-on-disk-option: help: do not expect built-in commands to be hardlinked
2020-10-08Merge branch 'js/ghwf-setup-msbuild-update'Libravatar Junio C Hamano1-1/+1
CI update. * js/ghwf-setup-msbuild-update: GitHub workflow: automatically follow minor updates of setup-msbuild
2020-10-08Merge branch 'jk/index-pack-hotfixes'Libravatar Junio C Hamano2-17/+19
Hotfix and clean-up for the jt/threaded-index-pack topic that has graduated to v2.29-rc0. * jk/index-pack-hotfixes: index-pack: make get_base_data() comment clearer index-pack: drop type_cas mutex index-pack: restore "resolving deltas" progress meter
2020-10-08Merge branch 'dl/mingw-header-cleanup'Libravatar Junio C Hamano1-1/+1
Header clean-up. * dl/mingw-header-cleanup: compat/mingw.h: drop extern from function declaration
2020-10-08Merge branch 'hx/push-atomic-with-cert'Libravatar Junio C Hamano1-4/+3
Hotfix to a recently added test script. * hx/push-atomic-with-cert: t5534: split stdout and stderr redirection
2020-10-08doc: fix the bnf like style of some commandsLibravatar Jean-Noël Avila2-2/+2
In command line options, variables are entered between < and > Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08doc: git-remote fix upsLibravatar Jean-Noël Avila1-10/+10
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08doc: use linkgit macro where needed.Libravatar Jean-Noël Avila1-1/+1
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08git-bisect-lk2009: make continuation of list indentedLibravatar Jean-Noël Avila1-8/+8
That's clearer asciidoc formatting. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08ci: do not skip tagged revisions in GitHub workflowsLibravatar Johannes Schindelin1-0/+2
When `master` is tagged, and then both `master` and the tag are pushed, Travis CI will happily build both. That is a waste of energy, which is why we skip the build for `master` in that case. Our GitHub workflow is also triggered by tags. However, the run would fail because the `windows-test` jobs are _not_ skipped on tags, but the `windows-build` job _is skipped (and therefore fails to upload the build artifacts needed by the test jobs). In addition, we just added logic to our GitHub workflow that will skip runs altogether if there is already a successful run for the same commit or at least for the same tree. Let's just change the GitHub workflow to no longer specifically skip tagged revisions. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08ci: skip GitHub workflow runs for already-tested commits/treesLibravatar Johannes Schindelin1-1/+38
When pushing a commit that has already passed a CI or PR build successfully, it makes sense to save some energy and time and skip the new build. Let's teach our GitHub workflow to do that. For good measure, we also compare the tree ID, which is what we actually test (the commit ID might have changed due to a reworded commit message, which should not affect the outcome of the run). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08tests: avoid using the branch name `main`Libravatar Johannes Schindelin4-16/+16
In the near future, we want to change Git's default branch name to `main`. In preparation for that, stop using it as a branch name in the test suite. Replace that branch name by `topic`, the same name we used to rename variations of `master` in b6211b89eb3 (tests: avoid variations of the `master` branch name, 2020-09-26). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08t1415: avoid using `main` as ref nameLibravatar Johannes Schindelin1-9/+9
In preparation for a patch series that will change the fall-back for `init.defaultBranch` to `main`, let's not use `main` as ref name in this test script. Otherwise, the `git for-each-ref ... | grep main` which wants to catch those refs would also unexpectedly catch `refs/heads/main`. Since the refs in question are worktree-local ones (i.e. each worktree has their own, just like `HEAD`), and since the test case already uses a secondary worktree called "second", let's use the name "first" for those refs instead. While at it, adjust the test titles that talk about a "repo" when they meant a "worktree" instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08Makefile: ASCII-sort += listsLibravatar Denton Liu1-5/+5
In 805d9eaf5e (Makefile: ASCII-sort += lists, 2020-03-21), the += lists in the Makefile were sorted into ASCII order. Since then, more out of order elements have been introduced. Sort these lists back into ASCII order. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08Merge branch 'st/dark-mode' into masterLibravatar Pratyush Yadav2-6/+49
Improve dark mode support. Do not hard-code widget colors and instead pull them from the current theme and update them in the options database. * st/dark-mode: git-gui: improve dark mode support
2020-10-07help: do not expect built-in commands to be hardlinkedLibravatar Johannes Schindelin3-0/+22
When building with SKIP_DASHED_BUILT_INS=YesPlease, the built-in commands are no longer present in the `PATH` as hardlinks to `git`. As a consequence, `load_command_list()` needs to be taught to find the names of the built-in commands from elsewhere. This only affected the output of `git --list-cmds=main`, but not the output of `git help -a` because the latter includes the built-in commands by virtue of them being listed in command-list.txt. The bug was detected via a patch series that turns the merge strategies included in Git into built-in commands: `git merge -s help` relies on `load_command_list()` to determine the list of available merge strategies. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07index-pack: make get_base_data() comment clearerLibravatar Jonathan Tan1-11/+8
A comment mentions that we may free cached delta bases via find_unresolved_deltas(), but that function went away in f08cbf60fe (index-pack: make quantum of work smaller, 2020-09-08). Since we need to rewrite that comment anyway, make the entire comment clearer. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07index-pack: drop type_cas mutexLibravatar Jeff King1-6/+0
The type_cas lock lost all of its callers in f08cbf60fe (index-pack: make quantum of work smaller, 2020-09-08), so we can safely delete it. The compiler didn't alert us that the variable became unused, because we still call pthread_mutex_init() and pthread_mutex_destroy() on it. It's worth considering also whether that commit was in error to remove the use of the lock. Why don't we need it now, if we did before, as described in ab791dd138 (index-pack: fix race condition with duplicate bases, 2014-08-29)? I think the answer is that we now look at and assign the child_obj->real_type field in the main thread while holding the work_lock(). So we don't have to worry about racing with the worker threads. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07index-pack: restore "resolving deltas" progress meterLibravatar Jeff King2-0/+11
Commit f08cbf60fe (index-pack: make quantum of work smaller, 2020-09-08) refactored the main loop in threaded_second_pass(), but also deleted the call to display_progress() at the top of the loop. This means that users typically see no progress at all during the delta resolution phase (and for large repositories, Git appears to hang). This looks like an accident that was unrelated to the intended change of that commit, since we continue to update nr_resolved_deltas in resolve_delta(). Let's restore the call to get that progress back. We'll also add a test that confirms we generate the expected progress. This isn't perfect, as it wouldn't catch a bug where progress was delayed to the end. That was probably possible to trigger when receiving a thin pack, because we'd eventually call display_progress() from fix_unresolved_deltas(), but only once after doing all the work. However, since our test case generates a complete pack, it reliably demonstrates this particular bug and its fix. And we can't do better without making the test racy. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07compat/mingw.h: drop extern from function declarationLibravatar Denton Liu1-1/+1
In 554544276a (*.[ch]: remove extern from function declarations using spatch, 2019-04-29), `extern` on function declarations were declared to be redundant and thus removed from the codebase. An `extern` was accidentally reintroduced in 08809c09aa (mingw: add a helper function to attach GDB to the current process, 2020-02-13). Remove this spurious `extern`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07GitHub workflow: automatically follow minor updates of setup-msbuildLibravatar Johannes Schindelin1-1/+1
It is the custom to follow minor updates of GitHub Actions automatically, by using the suffix `@v1`. Actions' maintainers will then update that `v1` ref to point to the newest. However, for `microsoft/setup-msbuild`, 889cacb6897 (ci: configure GitHub Actions for CI/PR, 2020-04-11) uses a very specific `@v1.0.0` suffix. In this instance, that is a problem: should `setup-msbuild` release a new version that intends to fix a critical bug, we won't know it, and we won't use it. Such a scenario is not theoretical. It is happening right now: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands Let's simplify our setup, allowing us to benefit from automatically using the newest v1.x. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07git-gui: improve dark mode supportLibravatar Serg Tereshchenko2-6/+49
The colors of some ttext widgets are hard-coded. These hard-coded colors are okay with a light theme but with a dark theme some widgets are dark colored and the hard-coded ones are still light. This defeats the purpose of applying the theme and makes the UI look very awkward. Remove the hard-coded colors in ttext calls and use colors from the theme for those widgets via Text.Background and Text.Foreground from the option database. Similarly, the highlighting for the currently selected file(s) in the "Staged Files" and "Unstaged Files" sections is also hard-coded. Pull the colors for that from the current theme to make sure it is in line Signed-off-by: Serg Tereshchenko <serg.partizan@gmail.com> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2020-10-06t5534: split stdout and stderr redirectionLibravatar Đoàn Trần Công Danh1-4/+3
On atomic pushing failure with GnuPG, we expect a very specific output in stdout due to `--porcelain` switch. On such failure, we also write down some helpful hint into stderr in order to help user understand what happens and how to continue from those failures. On a lot of system, those hint (in stderr) will be flushed first, then those messages in stdout will be flushed. In such systems, the current test code is fine as is. However, we don't have such guarantee, (at least) there're some real systems that writes those stream interleaved. On such systems, we may see the stderr stream written in the middle of stdout stream. Let's split those stream redirection. By splitting those stream, the output stream will contain exactly what we want to compare, thus, saving us a "sed" invocation. While we're at it, change the `test_i18ncmp` to `test_cmp` because we will never translate those messages (because of `--porcelain`). Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-05Git 2.29-rc0Libravatar Junio C Hamano2-1/+32
Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 18:53:32 +0000