summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-11-10Merge branch 'hv/bitshift-constants-in-blame'Libravatar Junio C Hamano1-12/+12
Move the definition of a set of bitmask constants from 0ctal literal to (1U<<count) notation. * hv/bitshift-constants-in-blame: builtin/blame.c: constants into bit shift format
2019-11-10Merge branch 'dd/notes-copy-default-dst-to-head'Libravatar Junio C Hamano3-8/+46
"git notes copy $original" ought to copy the notes attached to the original object to HEAD, but a mistaken tightening to command line parameter validation made earlier disabled that feature by mistake. * dd/notes-copy-default-dst-to-head: notes: fix minimum number of parameters to "copy" subcommand t3301: test diagnose messages for too few/many paramters
2019-11-10Merge branch 'pw/post-commit-from-sequencer'Libravatar Junio C Hamano6-265/+432
"rebase -i" ceased to run post-commit hook by mistake in an earlier update, which has been corrected. * pw/post-commit-from-sequencer: sequencer: run post-commit hook move run_commit_hook() to libgit and use it there sequencer.h fix placement of #endif t3404: remove uneeded calls to set_fake_editor t3404: set $EDITOR in subshell t3404: remove unnecessary subshell
2019-11-10Merge branch 'dl/format-patch-cover-from-desc'Libravatar Junio C Hamano5-34/+296
The branch description ("git branch --edit-description") has been used to fill the body of the cover letters by the format-patch command; this has been enhanced so that the subject can also be filled. * dl/format-patch-cover-from-desc: format-patch: teach --cover-from-description option format-patch: use enum variables format-patch: replace erroneous and condition
2019-11-10Merge branch 'es/walken-tutorial'Libravatar Junio C Hamano2-0/+907
A tutorial on object enumeration. * es/walken-tutorial: documentation: add tutorial for object walking
2019-11-10Merge branch 'jt/fetch-pack-record-refs-in-the-dot-promisor'Libravatar Junio C Hamano3-4/+58
Debugging support for lazy cloning has been a bit improved. * jt/fetch-pack-record-refs-in-the-dot-promisor: fetch-pack: write fetched refs to .promisor
2019-11-04Git 2.24Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-04Merge branch 'bc/doc-use-docbook-5'Libravatar Junio C Hamano1-1/+2
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'Libravatar Junio C Hamano4-6/+25
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'Libravatar Junio C Hamano1-2/+2
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-guiLibravatar Junio C Hamano4-21/+210
* 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-poLibravatar Junio C Hamano10-22221/+23300
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~2Libravatar Jiang Xin1-2439/+2539
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 noteLibravatar Elijah Newren1-4/+3
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 templateLibravatar Martin Ågren1-1/+2
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: typofixLibravatar Elijah Newren1-1/+1
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-31l10n: de.po: Update German translationLibravatar Matthias Rüster1-2454/+2590
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)Libravatar Peter Krefting1-2455/+2581
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2019-10-30Git 2.24-rc2Libravatar Junio C Hamano1-0/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-30Merge branch 'wb/fsmonitor-bitmap-fix'Libravatar Junio C Hamano1-3/+5
Comment update. * wb/fsmonitor-bitmap-fix: t7519-status-fsmonitor: improve comments
2019-10-30Merge branch 'rl/gitweb-blame-prev-fix'Libravatar Junio C Hamano1-1/+1
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'Libravatar Junio C Hamano1-0/+2
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/gitLibravatar Jiang Xin1-2454/+2586
* '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-poLibravatar Jiang Xin1-2541/+2679
* 'next' of github.com:ChrisADR/git-po: l10n: es: 2.24.0 round 2
2019-10-30t7519-status-fsmonitor: improve commentsLibravatar William Baker1-3/+5
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)Libravatar Alexander Shopov1-87/+51
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2019-10-29l10n: vi(4694t): Updated translation for v2.24.0Libravatar Tran Ngoc Quan1-2454/+2586
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2019-10-28l10n: es: 2.24.0 round 2Libravatar Christopher Diaz Riveros1-2541/+2679
Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com>
2019-10-29Merge branch 'l10n/it/update-italian-translation'Libravatar Jiang Xin1-61/+67
* '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 #2Libravatar Alessandro Menti1-61/+67
Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>
2019-10-28l10n: fr v2.24.0 rnd2Libravatar Jean-Noël Avila1-55/+75
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2019-10-28l10n: git.pot: v2.24.0 round 2 (1 new)Libravatar Jiang Xin1-45/+50
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 masterLibravatar Jiang Xin27-29/+247
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()`Libravatar Johannes Schindelin1-0/+2
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 modeLibravatar Robert Luberda1-1/+1
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 fetchLibravatar Derrick Stolee4-7/+10
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 bugLibravatar Derrick Stolee1-0/+16
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-rc1Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24Merge branch 'sg/ci-osx-gcc8-fix'Libravatar Junio C Hamano1-0/+1
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'Libravatar Junio C Hamano2-1/+5
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'Libravatar Junio C Hamano1-0/+5
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'Libravatar Junio C Hamano1-5/+8
Test update. * bw/format-patch-o-create-leading-dirs: t4014: make output-directory tests self-contained
2019-10-24Merge branch 'dl/submodule-set-branch'Libravatar Junio C Hamano1-3/+3
Test update. * dl/submodule-set-branch: t7419: change test_must_fail to ! for grep
2019-10-24fetch: delay fetch_if_missing=0 until after configLibravatar Jonathan Tan1-2/+2
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.versionLibravatar Derrick Stolee2-1/+5
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 jobLibravatar SZEDER Gábor1-0/+1
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 batchLibravatar Junio C Hamano1-0/+10
The tenth was at -rc0 ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23Merge branch 'cb/pcre2-chartables-leakfix'Libravatar Junio C Hamano3-3/+47
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'Libravatar Junio C Hamano5-3/+62
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'Libravatar Junio C Hamano3-5/+65
A segfault fix. * wb/fsmonitor-bitmap-fix: fsmonitor: don't fill bitmap with entries to be removed