summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-11-06trace2: add dots directly to strbuf in perf_fmt_prepare()René Scharfe
The initialization function of the Trace2 performance format target sets aside a stash of dots for indenting output. Get rid of it and use strbuf_addchars() to provide dots on demand instead. This shortens the code, gets rid of a small heap allocation and is a bit more efficient. Signed-off-by: René Scharfe <l.s.r@web.de> Acked-by: Jeff King <peff@peff.net> Acked-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-04Git 2.24v2.24.0Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-04Merge branch 'bc/doc-use-docbook-5'Junio C Hamano
Finishing touches to the recent update to the build procedure for the documentation. * bc/doc-use-docbook-5: manpage-bold-literal.xsl: match for namespaced "d:literal" in template
2019-11-04Merge branch 'ds/commit-graph-on-fetch'Junio C Hamano
Regression fix. * ds/commit-graph-on-fetch: commit-graph: fix writing first commit-graph during fetch t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug
2019-11-04Merge branch 'jt/delay-fetch-if-missing'Junio C Hamano
Work-around a lazy fetch glitch. * jt/delay-fetch-if-missing: fetch: delay fetch_if_missing=0 until after config
2019-11-04Merge https://github.com/prati0100/git-guiJunio C Hamano
* https://github.com/prati0100/git-gui: git-gui: improve Japanese translation git-gui: add a readme git-gui: support for diff3 conflict style git-gui: use existing interface to query a path's attribute git-gui (Windows): use git-bash.exe if it is available treewide: correct several "up-to-date" to "up to date" Fix build with core.autocrlf=true
2019-11-04Merge tag 'l10n-2.24.0-rnd2' of https://github.com/git-l10n/git-poJunio C Hamano
l10n-2.24.0-rnd2 * tag 'l10n-2.24.0-rnd2' of https://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.24.0 l10n round 1~2 l10n: de.po: Update German translation l10n: sv.po: Update Swedish translation (4695t0f0u) l10n: bg.po: Updated Bulgarian translation (4694) l10n: vi(4694t): Updated translation for v2.24.0 l10n: es: 2.24.0 round 2 l10n: it.po: update the Italian translation for Git 2.24.0 round #2 l10n: fr v2.24.0 rnd2 l10n: git.pot: v2.24.0 round 2 (1 new) l10n: it.po: update the Italian translation for Git 2.24.0 l10n: fr 2.24.0 rnd 1 l10n: git.pot: v2.24.0 round 1 (35 new, 16 removed) l10n: bg.po: Updated Bulgarian translation (4693) l10n: sv.po: Update Swedish translation (4674t0f0u) l10n: Update Catalan translation
2019-11-02l10n: zh_CN: for git v2.24.0 l10n round 1~2Jiang Xin
Translate 36 new messages (4694t0f0u) for git 2.24.0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2019-11-02RelNotes/2.24.0: fix self-contradictory noteElijah Newren
As per Wikipedia, "In current technical usage, for one to state that a feature is deprecated is merely a recommendation against using it." It is thus contradictory to claim that something is not "officially deprecated" and then to immediately state that we are both discouraging its use and pointing people elsewhere. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-02manpage-bold-literal.xsl: match for namespaced "d:literal" in templateMartin Ågren
We recently regressed our rendering with Asciidoctor of "literal" elements in our manpages, i.e, stuff we have placed within `backticks` in order to render as monospace. In particular, we lost the bold rendering of such literal text. The culprit is f6461b82b9 ("Documentation: fix build with Asciidoctor 2", 2019-09-15), where we switched from DocBook 4.5 to DocBook 5 with Asciidoctor. As part of the switch, we started using the namespaced DocBook XSLT stylesheets rather than the non-namespaced ones. (See f6461b82b9 for more details on why we changed to the namespaced ones.) The bold literals are implemented as an XSLT snippet <xsl:template match="literal">...</xsl:template>. Now that we use namespaces, this doesn't pick up our literals like it used to. Match for "d:literal" in addition to just "literal", after defining the d namespace. ("d" is what http://docbook.sourceforge.net/release/xsl-ns/current/manpages/docbook.xsl uses.) Note that we need to keep matching without the namespace for AsciiDoc. This boldness was introduced by 5121a6d993 ("Documentation: option to render literal text as bold for manpages", 2009-03-27) and made the default in 5945717009 ("Documentation: bold literals in man", 2016-05-31). One reason this was not caught in review is that our doc-diff tool diffs without any boldness, i.e., it "only" compares text. As pointed out by Peff in review of this patch, one can use `MAN_KEEP_FORMATTING=1 ./doc-diff <...>` This has been optically tested with AsciiDoc 8.6.10, Asciidoctor 1.5.5 and Asciidoctor 2.0.10. I've also verified that doc-diff produces the empty output for all three programs, as expected, and that with the MAN_KEEP_FORMATTING trick, AsciiDoc yields no diff, whereas with Asciidoctor, we get bold literals, just like we want. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Acked-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-02RelNotes/2.24.0: typofixElijah Newren
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-31l10n: de.po: Update German translationMatthias Rüster
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>
2019-10-30l10n: sv.po: Update Swedish translation (4695t0f0u)Peter Krefting
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2019-10-30Git 2.24-rc2v2.24.0-rc2Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-30Merge branch 'wb/fsmonitor-bitmap-fix'Junio C Hamano
Comment update. * wb/fsmonitor-bitmap-fix: t7519-status-fsmonitor: improve comments
2019-10-30Merge branch 'rl/gitweb-blame-prev-fix'Junio C Hamano
Fix a rather old bug in gitweb---incremental blame output in javascript actions mode never worked. * rl/gitweb-blame-prev-fix: gitweb: correctly store previous rev in javascript-actions mode
2019-10-30Merge branch 'js/mingw-needs-hiding-fix'Junio C Hamano
Fix for a (rather old) buffer-overrun bug. * js/mingw-needs-hiding-fix: mingw: avoid a buffer overrun in `needs_hiding()`
2019-10-30Merge branch 'master' of github.com:vnwildman/gitJiang Xin
* 'master' of github.com:vnwildman/git: l10n: vi(4694t): Updated translation for v2.24.0
2019-10-30Merge branch 'next' of github.com:ChrisADR/git-poJiang Xin
* 'next' of github.com:ChrisADR/git-po: l10n: es: 2.24.0 round 2
2019-10-30t7519-status-fsmonitor: improve commentsWilliam Baker
The comments for the staging/unstaging test did not accurately describe the scenario being tested. It is not essential that the test files being staged/unstaged appear at the end of the index. All that is required is that the test files are not flagged with CE_FSMONITOR_VALID and have a position in the index greater than the number of entries in the index after unstaging. The comment for this test has been updated to be more accurate with respect to the scenario that's being tested. Signed-off-by: William Baker <William.Baker@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-29l10n: bg.po: Updated Bulgarian translation (4694)Alexander Shopov
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2019-10-29l10n: vi(4694t): Updated translation for v2.24.0Tran Ngoc Quan
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2019-10-29l10n: es: 2.24.0 round 2Christopher Diaz Riveros
Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com>
2019-10-28Merge branch 'l10n/it/update-italian-translation'Jiang Xin
* 'update-italian-translation' of github.com:AlessandroMenti/git-po: l10n: it.po: update the Italian translation for Git 2.24.0 round #2
2019-10-28l10n: it.po: update the Italian translation for Git 2.24.0 round #2Alessandro Menti
Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>
2019-10-28l10n: fr v2.24.0 rnd2Jean-Noël Avila
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2019-10-28l10n: git.pot: v2.24.0 round 2 (1 new)Jiang Xin
Generate po/git.pot from v2.24.0-rc1 for git v2.24.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2019-10-28Merge tag 'v2.24.0-rc1' of github.com:git/git into masterJiang Xin
Git 2.24-rc1 * tag 'v2.24.0-rc1' of github.com:git/git: Git 2.24-rc1 repo-settings: read an int for index.version ci: fix GCC install in the Travis CI GCC OSX job Eleventh batch ci(osx): use new location of the `perforce` cask t7419: change test_must_fail to ! for grep t4014: make output-directory tests self-contained ci(visual-studio): actually run the tests in parallel ci(visual-studio): use strict compile flags, and optimization userdiff: fix some corner cases in dts regex test-progress: fix test failures on big-endian systems completion: clarify installation instruction for zsh grep: avoid leak of chartables in PCRE2 grep: make PCRE2 aware of custom allocator grep: make PCRE1 aware of custom allocator remote-curl: pass on atomic capability to remote side diff-highlight: fix a whitespace nit fsmonitor: don't fill bitmap with entries to be removed
2019-10-28mingw: avoid a buffer overrun in `needs_hiding()`Johannes Schindelin
When this function is passed a path with a trailing slash, it runs right over the end of that path. Let's fix this. Co-authored-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-28gitweb: correctly store previous rev in javascript-actions modeRobert Luberda
Without this change, the setting $feature{'javascript-actions'}{'default'} = [1]; in gitweb.conf breaks gitweb's blame page: clicking on line numbers displayed in the second column on the page has no effect. For comparison, with javascript-actions disabled, clicking on line numbers loads the previous version of the line. Addresses https://bugs.debian.org/741883. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Robert Luberda <robert@debian.org> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-25commit-graph: fix writing first commit-graph during fetchDerrick Stolee
The previous commit includes a failing test for an issue around fetch.writeCommitGraph and fetching in a repo with a submodule. Here, we fix that bug and set the test to "test_expect_success". The problem arises with this set of commands when the remote repo at <url> has a submodule. Note that --recurse-submodules is not needed to demonstrate the bug. $ git clone <url> test $ cd test $ git -c fetch.writeCommitGraph=true fetch origin Computing commit graph generation numbers: 100% (12/12), done. BUG: commit-graph.c:886: missing parent <hash1> for commit <hash2> Aborted (core dumped) As an initial fix, I converted the code in builtin/fetch.c that calls write_commit_graph_reachable() to instead launch a "git commit-graph write --reachable --split" process. That code worked, but is not how we want the feature to work long-term. That test did demonstrate that the issue must be something to do with internal state of the 'git fetch' process. The write_commit_graph() method in commit-graph.c ensures the commits we plan to write are "closed under reachability" using close_reachable(). This method walks from the input commits, and uses the UNINTERESTING flag to mark which commits have already been visited. This allows the walk to take O(N) time, where N is the number of commits, instead of O(P) time, where P is the number of paths. (The number of paths can be exponential in the number of commits.) However, the UNINTERESTING flag is used in lots of places in the codebase. This flag usually means some barrier to stop a commit walk, such as in revision-walking to compare histories. It is not often cleared after the walk completes because the starting points of those walks do not have the UNINTERESTING flag, and clear_commit_marks() would stop immediately. This is happening during a 'git fetch' call with a remote. The fetch negotiation is comparing the remote refs with the local refs and marking some commits as UNINTERESTING. I tested running clear_commit_marks_many() to clear the UNINTERESTING flag inside close_reachable(), but the tips did not have the flag, so that did nothing. It turns out that the calculate_changed_submodule_paths() method is at fault. Thanks, Peff, for pointing out this detail! More specifically, for each submodule, the collect_changed_submodules() runs a revision walk to essentially do file-history on the list of submodules. That revision walk marks commits UNININTERESTING if they are simplified away by not changing the submodule. Instead, I finally arrived on the conclusion that I should use a flag that is not used in any other part of the code. In commit-reach.c, a number of flags were defined for commit walk algorithms. The REACHABLE flag seemed like it made the most sense, and it seems it was not actually used in the file. The REACHABLE flag was used in early versions of commit-reach.c, but was removed by 4fbcca4 (commit-reach: make can_all_from_reach... linear, 2018-07-20). Add the REACHABLE flag to commit-graph.c and use it instead of UNINTERESTING in close_reachable(). This fixes the bug in manual testing. Reported-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Jeff King <peff@peff.net> Helped-by: Szeder Gábor <szeder.dev@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-25t5510-fetch.sh: demonstrate fetch.writeCommitGraph bugDerrick Stolee
While dogfooding, Johannes found a bug in the fetch.writeCommitGraph config behavior. His example initially happened during a clone with --recurse-submodules, we found that this happens with the first fetch after cloning a repository that contains a submodule: $ git clone <url> test $ cd test $ git -c fetch.writeCommitGraph=true fetch origin Computing commit graph generation numbers: 100% (12/12), done. BUG: commit-graph.c:886: missing parent <hash1> for commit <hash2> Aborted (core dumped) In the repo I had cloned, there were really 60 commits to scan, but only 12 were in the list to write when calling compute_generation_numbers(). A commit in the list expects to see a parent, but that parent is not in the list. A follow-up will fix the bug, but first we create a test that demonstrates the problem. This test must be careful about an existing commit-graph file, since GIT_TEST_COMMIT_GRAPH=1 will cause the repo we are cloning to already have one. This then prevents the incremtnal commit-graph write during the first 'git fetch'. Helped-by: Jeff King <peff@peff.net> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Szeder Gábor <szeder.dev@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24Git 2.24-rc1v2.24.0-rc1Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24Merge branch 'sg/ci-osx-gcc8-fix'Junio C Hamano
CI build fix. * sg/ci-osx-gcc8-fix: ci: fix GCC install in the Travis CI GCC OSX job
2019-10-24Merge branch 'ds/feature-macros'Junio C Hamano
The codepath that reads the index.version configuration was broken with a recent update, which has been corrected. * ds/feature-macros: repo-settings: read an int for index.version
2019-10-24Merge branch 'js/azure-ci-osx-fix'Junio C Hamano
Update installation procedure for Perforce on MacOS in the CI jobs running on Azure pipelines, which was failing. * js/azure-ci-osx-fix: ci(osx): use new location of the `perforce` cask
2019-10-24Merge branch 'bw/format-patch-o-create-leading-dirs'Junio C Hamano
Test update. * bw/format-patch-o-create-leading-dirs: t4014: make output-directory tests self-contained
2019-10-24Merge branch 'dl/submodule-set-branch'Junio C Hamano
Test update. * dl/submodule-set-branch: t7419: change test_must_fail to ! for grep
2019-10-24fetch: delay fetch_if_missing=0 until after configJonathan Tan
Suppose, from a repository that has ".gitmodules", we clone with --filter=blob:none: git clone --filter=blob:none --no-checkout \ https://kernel.googlesource.com/pub/scm/git/git Then we fetch: git -C git fetch This will cause a "unable to load config blob object", because the fetch_config_from_gitmodules() invocation in cmd_fetch() will attempt to load ".gitmodules" (which Git knows to exist because the client has the tree of HEAD) while fetch_if_missing is set to 0. fetch_if_missing is set to 0 too early - ".gitmodules" here should be lazily fetched. Git must set fetch_if_missing to 0 before the fetch because as part of the fetch, packfile negotiation happens (and we do not want to fetch any missing objects when checking existence of objects), but we do not need to set it so early. Move the setting of fetch_if_missing to the earliest possible point in cmd_fetch(), right before any fetching happens. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24repo-settings: read an int for index.versionDerrick Stolee
Several config options were combined into a repo_settings struct in ds/feature-macros, including a move of the "index.version" config setting in 7211b9e (repo-settings: consolidate some config settings, 2019-08-13). Unfortunately, that file looked like a lot of boilerplate and what is clearly a factor of copy-paste overload, the config setting is parsed with repo_config_ge_bool() instead of repo_config_get_int(). This means that a setting "index.version=4" would not register correctly and would revert to the default version of 3. I caught this while incorporating v2.24.0-rc0 into the VFS for Git codebase, where we really care that the index is in version 4. This was not caught by the codebase because the version checks placed in t1600-index.sh did not test the "basic" scenario enough. Here, we modify the test to include these normal settings to not be overridden by features.manyFiles or GIT_INDEX_VERSION. While the "default" version is 3, this is demoted to version 2 in do_write_index() when not necessary. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24ci: fix GCC install in the Travis CI GCC OSX jobSZEDER Gábor
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-23Eleventh batchJunio C Hamano
The tenth was at -rc0 ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23Merge branch 'cb/pcre2-chartables-leakfix'Junio C Hamano
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-23Merge branch 'bc/smart-http-atomic-push'Junio C Hamano
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-23Merge branch 'wb/fsmonitor-bitmap-fix'Junio C Hamano
A segfault fix. * wb/fsmonitor-bitmap-fix: fsmonitor: don't fill bitmap with entries to be removed
2019-10-23Merge branch 'sb/userdiff-dts'Junio C Hamano
Tweak userdiff patterns for dts. * sb/userdiff-dts: userdiff: fix some corner cases in dts regex
2019-10-23Merge branch 'sg/progress-fix'Junio C Hamano
Byte-order fix the recent update to progress display code. * sg/progress-fix: test-progress: fix test failures on big-endian systems
2019-10-23Merge branch 'nr/diff-highlight-indent-fix'Junio C Hamano
Code cleanup. * nr/diff-highlight-indent-fix: diff-highlight: fix a whitespace nit
2019-10-23Merge branch 'mb/clarify-zsh-completion-doc'Junio C Hamano
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-23ci(osx): use new location of the `perforce` caskJohannes Schindelin
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>