summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-30Merge branch 'sk/typofixes' into masterLibravatar Junio C Hamano4-4/+4
* sk/typofixes: comment: fix spelling mistakes inside comments
2020-07-30First batch post 2.28Libravatar Junio C Hamano2-1/+68
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30Merge branch 'en/fill-directory-exponential' into masterLibravatar Junio C Hamano2-2/+27
Fix to a regression introduced during 2.27 cycle. * en/fill-directory-exponential: dir: check pathspecs before returning `path_excluded`
2020-07-30Merge branch 'ct/mv-unmerged-path-error' into masterLibravatar Junio C Hamano2-2/+22
"git mv src dst", when src is an unmerged path, errored out correctly but with an incorrect error message to claim that src is not tracked, which has been clarified. * ct/mv-unmerged-path-error: git-mv: improve error message for conflicted file
2020-07-30Merge branch 'bc/push-cas-cquoted-refname' into masterLibravatar Junio C Hamano2-1/+20
Pushing a ref whose name contains non-ASCII character with the "--force-with-lease" option did not work over smart HTTP protocol, which has been corrected. * bc/push-cas-cquoted-refname: remote-curl: make --force-with-lease work with non-ASCII ref names
2020-07-30Merge branch 'cc/pretty-contents-size' into masterLibravatar Junio C Hamano3-7/+65
"git for-each-ref --format=<>" learned %(contents:size). * cc/pretty-contents-size: ref-filter: add support for %(contents:size) t6300: test refs pointing to tree and blob Documentation: clarify %(contents:XXXX) doc
2020-07-30Merge branch 'rs/add-index-entry-optim-fix' into masterLibravatar Junio C Hamano1-14/+0
Fix to an ancient bug caused by an over-eager attempt for optimization. * rs/add-index-entry-optim-fix: read-cache: remove bogus shortcut
2020-07-30Merge branch 'jt/avoid-lazy-fetching-upon-have-check' into masterLibravatar Junio C Hamano2-2/+42
Fetching from a lazily cloned repository resulted at the server side in attempts to lazy fetch objects that the client side has, many of which will not be available from the third-party anyway. * jt/avoid-lazy-fetching-upon-have-check: upload-pack: do not lazy-fetch "have" objects
2020-07-30Merge branch 'dl/test-must-fail-fixes-6' into masterLibravatar Junio C Hamano7-7/+86
Dev support to limit the use of test_must_fail to only git commands. * dl/test-must-fail-fixes-6: test-lib-functions: restrict test_must_fail usage t9400: don't use test_must_fail with cvs t9834: remove use of `test_might_fail p4` t7107: don't use test_must_fail() t5324: reorder `run_with_limited_open_files test_might_fail` t3701: stop using `env` in force_color()
2020-07-30Merge branch 'jk/reject-newer-extensions-in-v0' into masterLibravatar Junio C Hamano3-16/+85
With the base fix to 2.27 regresion, any new extensions in a v0 repository would still be silently honored, which is not quite right. Instead, complain and die loudly. * jk/reject-newer-extensions-in-v0: verify_repository_format(): complain about new extensions in v0 repo
2020-07-30Merge branch 'hn/reftable' into masterLibravatar Junio C Hamano7-26/+51
Preliminary clean-up of the refs API in preparation for adding a new refs backend "reftable". * hn/reftable: reflog: cleanse messages in the refs.c layer bisect: treat BISECT_HEAD as a pseudo ref t3432: use git-reflog to inspect the reflog for HEAD lib-t6000.sh: write tag using git-update-ref
2020-07-30Merge branch 'bw/fail-cloning-into-non-empty' into masterLibravatar Junio C Hamano2-3/+13
"git clone --separate-git-dir=$elsewhere" used to stomp on the contents of the existing directory $elsewhere, which has been taught to fail when $elsewhere is not an empty directory. * bw/fail-cloning-into-non-empty: git clone: don't clone into non-empty directory
2020-07-30Merge branch 'pb/log-rev-list-doc' into masterLibravatar Junio C Hamano4-40/+71
"git help log" has been enhanced by sharing more material from the documentation for the underlying "git rev-list" command. * pb/log-rev-list-doc: git-log.txt: include rev-list-description.txt git-rev-list.txt: move description to separate file git-rev-list.txt: tweak wording in set operations git-rev-list.txt: fix Asciidoc syntax revisions.txt: describe 'rev1 rev2 ...' meaning for ranges git-log.txt: add links to 'rev-list' and 'diff' docs
2020-07-30Merge branch 'jk/tests-timestamp-fix' into masterLibravatar Junio C Hamano5-8/+17
The test framework has been updated so that most tests will run with predictable (artificial) timestamps. * jk/tests-timestamp-fix: t9100: stop depending on commit timestamps test-lib: set deterministic default author/committer date t9100: explicitly unset GIT_COMMITTER_DATE t5539: make timestamp requirements more explicit t9700: loosen ident timezone regex t6000: use test_tick consistently
2020-07-30Merge branch 'ds/commit-graph-bloom-updates' into masterLibravatar Junio C Hamano9-74/+217
Updates to the changed-paths bloom filter. * ds/commit-graph-bloom-updates: commit-graph: check all leading directories in changed path Bloom filters revision: empty pathspecs should not use Bloom filters revision.c: fix whitespace commit-graph: check chunk sizes after writing commit-graph: simplify chunk writes into loop commit-graph: unify the signatures of all write_graph_chunk_*() functions commit-graph: persist existence of changed-paths bloom: fix logic in get_bloom_filter() commit-graph: change test to die on parse, not load commit-graph: place bloom_settings in context
2020-07-30Merge branch 'sg/commit-graph-cleanups' into masterLibravatar Junio C Hamano13-108/+117
The changed-path Bloom filter is improved using ideas from an independent implementation. * sg/commit-graph-cleanups: commit-graph: simplify write_commit_graph_file() #2 commit-graph: simplify write_commit_graph_file() #1 commit-graph: simplify parse_commit_graph() #2 commit-graph: simplify parse_commit_graph() #1 commit-graph: clean up #includes diff.h: drop diff_tree_oid() & friends' return value commit-slab: add a function to deep free entries on the slab commit-graph-format.txt: all multi-byte numbers are in network byte order commit-graph: fix parsing the Chunk Lookup table tree-walk.c: don't match submodule entries for 'submod/anything'
2020-07-29comment: fix spelling mistakes inside commentsLibravatar Steve Kemp4-4/+4
This commit fixes a couple of minor spelling mistakes inside comments. Signed-off-by: Steve Kemp <steve@steve.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-26Git 2.28Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-26Merge tag 'l10n-2.28.0-rnd1' of https://www.github.com/git-l10n/git-po into ↵Libravatar Junio C Hamano11-11813/+14504
master l10n-2.28.0-rnd1 * tag 'l10n-2.28.0-rnd1' of https://www.github.com/git-l10n/git-po: l10n: es: 2.28.0 round 1 l10n: de.po: Update German translation for Git v2.28.0 l10n: de.po: fix grammar l10n: zh_CN: for git v2.28.0 l10n round 1 l10n: zh_TW.po: v2.28.0 round 1 (0 untranslated) l10n: vi.po: correct "ident line" translation l10n: vi.po(4931t): Updated translation for v2.28.0 l10n: fr v2.28.0 round 1 l10n: sv.po: Update Swedish translation (4931t0f0u) l10n: it.po: update the Italian translation for Git 2.28.0 round 1 l10n: tr: v2.28.0 round 1 l10n: git.pot: v2.28.0 round 1 (70 new, 14 removed) l10n: Update Catalan translation
2020-07-27Merge branch 'master' of github.com:Softcatala/git-poLibravatar Jiang Xin1-426/+428
* 'master' of github.com:Softcatala/git-po: l10n: Update Catalan translation
2020-07-26l10n: es: 2.28.0 round 1Libravatar Christopher Diaz Riveros1-1219/+1509
Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com>
2020-07-24Merge branch 'ps/ref-transaction-hook' into masterLibravatar Junio C Hamano1-2/+2
A new hook. * ps/ref-transaction-hook: githooks.txt: use correct "reference-transaction" hook name
2020-07-24githooks.txt: use correct "reference-transaction" hook nameLibravatar Bojun Chen1-2/+2
The "reference transaction" hook was introduced in commit 6754159767 (refs: implement reference transaction hook, 2020-06-19). The name of the hook is declared as "reference-transaction" in "refs.c" and testcases, but the name declared in "githooks.txt" is different. Signed-off-by: Bojun Chen <bojun.cbj@alibaba-inc.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-24l10n: de.po: Update German translation for Git v2.28.0Libravatar Matthias Rüster1-1160/+1420
Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
2020-07-24l10n: de.po: fix grammarLibravatar Ralf Thielow1-3/+3
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
2020-07-22Documentation/RelNotes: fix a typo in 2.28's relnotesLibravatar Taylor Blau1-1/+1
Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-22Git 2.28-rc2Libravatar Junio C Hamano2-1/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-21Merge branch 'en/sparse-status' into masterLibravatar Junio C Hamano1-2/+2
Fix to a "git prompt" regression during this development cycle. * en/sparse-status: git-prompt: change == to = for zsh's sake
2020-07-21l10n: zh_CN: for git v2.28.0 l10n round 1Libravatar Jiang Xin1-1122/+1368
Translate 70 new messages (4931t0f0u) for git 2.28.0. Reviewed-by: Fangyi Zhou <me@fangyi.io> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2020-07-21Merge branch 'l10n/zh_TW/200716' of github.com:l10n-tw/git-poLibravatar Jiang Xin1-1127/+1413
* 'l10n/zh_TW/200716' of github.com:l10n-tw/git-po: l10n: zh_TW.po: v2.28.0 round 1 (0 untranslated)
2020-07-20remote-curl: make --force-with-lease work with non-ASCII ref namesLibravatar brian m. carlson2-1/+20
When we invoke a remote transport helper and pass an option with an argument, we quote the argument as a C-style string if necessary. This is the case for the cas option, which implements the --force-with-lease command-line flag, when we're passing a non-ASCII refname. However, the remote curl helper isn't designed to parse such an argument, meaning that if we try to use --force-with-lease with an HTTP push and a non-ASCII refname, we get an error like this: error: cannot parse expected object name '0000000000000000000000000000000000000000"' Note the double quote, which get_oid has reminded us is not valid in an hex object ID. Even if we had been able to parse it, we would send the wrong data to the server: we'd send an escaped ref, which would not behave as the user wanted and might accidentally result in updating or deleting a ref we hadn't intended. Since we need to expect a quoted C-style string here, just check if the first argument is a double quote, and if so, unquote it. Note that if the refname contains a double quote, then we will have double-quoted it already, so there is no ambiguity. We test for this case only in the smart protocol, since the DAV-based protocol is not capable of handling this capability. We use UTF-8 because this is nicer in our tests and friendlier to Windows, but the code should work for all non-ASCII refs. While we're at it, since the name of the option is now well established and isn't going to change, let's inline it instead of using the #define constant. Reported-by: Frej Bjon <frej.bjon@nemit.fi> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-20git-prompt: change == to = for zsh's sakeLibravatar David J. Malan1-2/+2
When using git-prompt.sh with zsh, __git_ps1 currently errs when inside a repo with: __git_ps1:96: = not found Avoid using non-portable "==" that is only understood by bash and not zsh. Change to "=" so that the prompt script becomes usable with zsh again. Signed-off-by: David J. Malan <malan@harvard.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-20git-mv: improve error message for conflicted fileLibravatar Chris Torek2-2/+22
'git mv' has always complained about renaming a conflicted file, as it cannot handle multiple index entries for one file. However, the error message it uses has been the same as the one for an untracked file: fatal: not under version control, src=... which is patently wrong. Distinguish the two cases and add a test to make sure we produce the correct message. Signed-off-by: Chris Torek <chris.torek@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-20dir: check pathspecs before returning `path_excluded`Libravatar Martin Ågren2-2/+27
In 95c11ecc73 ("Fix error-prone fill_directory() API; make it only return matches", 2020-04-01), we taught `fill_directory()`, or more specifically `treat_path()`, to check against any pathspecs so that we could simplify the callers. But in doing so, we added a slightly-too-early return for the "excluded" case. We end up not checking the pathspecs, meaning we return `path_excluded` when maybe we should return `path_none`. As a result, `git status --ignored -- pathspec` might show paths that don't actually match "pathspec". Move the "excluded" check down to after we've checked any pathspecs. Reported-by: Andreas Schwab <schwab@linux-m68k.org> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-20Merge https://github.com/prati0100/git-gui into masterLibravatar Junio C Hamano1-24/+3
* https://github.com/prati0100/git-gui: git-gui: allow opening work trees from the startup dialog
2020-07-20l10n: zh_TW.po: v2.28.0 round 1 (0 untranslated)Libravatar Yi-Jyun Pan1-1127/+1413
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
2020-07-20l10n: vi.po: correct "ident line" translationLibravatar Đoàn Trần Công Danh1-6/+6
While we're at it, fix some minor misspelling and improve translation for 3-way-merging. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2020-07-20l10n: vi.po(4931t): Updated translation for v2.28.0Libravatar Tran Ngoc Quan1-1125/+1411
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2020-07-18Merge branch 'dl/branch-cleanup' into masterLibravatar Junio C Hamano1-2/+2
Last minute fix-up to tests for portability. * dl/branch-cleanup: t3200: don't grep for `strerror()` string
2020-07-18Merge branch 'js/pu-to-seen' into masterLibravatar Junio C Hamano1-1/+1
Last minute fix-up to documentation. * js/pu-to-seen: gitworkflows.txt: fix broken subsection underline
2020-07-18Merge branch 'jc/relnotes-v0-extension-update' into masterLibravatar Junio C Hamano1-9/+0
Last minute fix-up to the release notes. * jc/relnotes-v0-extension-update: RelNotes: update the v0 with extension situation
2020-07-18t3200: don't grep for `strerror()` stringLibravatar Martin Ågren1-2/+2
In 6b7093064a ("t3200: test for specific errors", 2020-06-15), we learned to grep stderr to ensure that the failing `git branch` invocations fail for the right reason. In two of these tests, we grep for "File exists", expecting the string to show up there since config.c calls `error_errno()`, which ends up including `strerror(errno)` in the error message. But as we saw in 4605a73073 ("t1091: don't grep for `strerror()` string", 2020-03-08), there exists at least one implementation where `strerror()` yields a slightly different string than the one we're grepping for. In particular, these tests fail on the NonStop platform. Similar to 4605a73073, grep for the beginning of the string instead to avoid relying on `strerror()` behavior. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-18gitworkflows.txt: fix broken subsection underlineLibravatar Martin Ågren1-1/+1
AsciiDoctor renders the "~~~~~~~~~" literally. That's not our intention: it is supposed to indicate a level 2 subsection. In 828197de8f ("docs: adjust for the recent rename of `pu` to `seen`", 2020-06-25), the length of this section header grew by two characters but we didn't adjust the number of ~ characters accordingly. AsciiDoc handles this discrepancy ok and still picks this up as a subsection title, but Asciidoctor is not as forgiving. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-17RelNotes: update the v0 with extension situationLibravatar Junio C Hamano1-9/+0
With the two-patch series for regression fix, to the users from 2.27 days, there is no visible behaviour change---we do not warn and fail use of v0 repositories with newer extensions yet, so there is nothing to note in the backward compatibility section. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-16Git 2.28-rc1Libravatar Junio C Hamano2-1/+9
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-16Merge branch 'jn/v0-with-extensions-fix' into masterLibravatar Junio C Hamano3-17/+23
In 2.28-rc0, we corrected a bug that some repository extensions are honored by mistake even in a version 0 repositories (these configuration variables in extensions.* namespace were supposed to have special meaning in repositories whose version numbers are 1 or higher), but this was a bit too big a change. * jn/v0-with-extensions-fix: repository: allow repository format upgrade with extensions Revert "check_repository_format_gently(): refuse extensions for old repositories"
2020-07-16upload-pack: do not lazy-fetch "have" objectsLibravatar Jonathan Tan2-2/+42
When upload-pack receives a request containing "have" hashes, it (among other things) checks if the served repository has the corresponding objects. However, it does not do so with the OBJECT_INFO_SKIP_FETCH_OBJECT flag, so if serving a partial clone, a lazy fetch will be triggered first. This was discovered at $DAYJOB when a user fetched from a partial clone (into another partial clone - although this would also happen if the repo to be fetched into is not a partial clone). Therefore, whenever "have" hashes are checked for existence, pass the OBJECT_INFO_SKIP_FETCH_OBJECT flag. Also add the OBJECT_INFO_QUICK flag to improve performance, as it is typical that such objects do not exist in the serving repo, and the consequences of a false negative are minor (usually, a slightly larger pack sent). Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-16ref-filter: add support for %(contents:size)Libravatar Christian Couder3-1/+28
It's useful and efficient to be able to get the size of the contents directly without having to pipe through `wc -c`. Also the result of the following: `git for-each-ref --format='%(contents)' refs/heads/my-branch | wc -c` is off by one as `git for-each-ref` appends a newline character after the contents, which can be seen by comparing its output with the output from `git cat-file`. As with %(contents), %(contents:size) is silently ignored, if a ref points to something other than a commit or a tag: ``` $ git update-ref refs/mytrees/first HEAD^{tree} $ git for-each-ref --format='%(contents)' refs/mytrees/first $ git for-each-ref --format='%(contents:size)' refs/mytrees/first ``` Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-16read-cache: remove bogus shortcutLibravatar René Scharfe1-14/+0
has_dir_name() has some optimizations for the case where entries are added to an index in the correct order. They kick in if the new entry sorts after the last one. One of them exits early if the last entry has a longer name than the directory of the new entry. Here's its comment: /* * The directory prefix lines up with part of * a longer file or directory name, but sorts * after it, so this sub-directory cannot * collide with a file. * * last: xxx/yy-file (because '-' sorts before '/') * this: xxx/yy/abc */ However, a file named xxx/yy would be sorted before xxx/yy-file because '-' sorts after NUL, so the length check against the last entry is not sufficient to rule out a collision. Remove it. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Suggested-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-16verify_repository_format(): complain about new extensions in v0 repoLibravatar Jeff King3-16/+85
We made the mistake in the past of respecting extensions.* even when the repository format version was set to 0. This is bad because forgetting to bump the repository version means that older versions of Git (which do not know about our extensions) won't complain. I.e., it's not a problem in itself, but it means your repository is in a state which does not give you the protection you think you're getting from older versions. For compatibility reasons, we are stuck with that decision for existing extensions. However, we'd prefer not to extend the damage further. We can do that by catching any newly-added extensions and complaining about the repository format. Note that this is a pretty heavy hammer: we'll refuse to work with the repository at all. A lesser option would be to ignore (possibly with a warning) any new extensions. But because of the way the extensions are handled, that puts the burden on each new extension that is added to remember to "undo" itself (because they are handled before we know for sure whether we are in a v1 repo or not, since we don't insist on a particular ordering of config entries). So one option would be to rewrite that handling to record any new extensions (and their values) during the config parse, and then only after proceed to handle new ones only if we're in a v1 repository. But I'm not sure if it's worth the trouble: - ignoring extensions is likely to end up with broken results anyway (e.g., ignoring a proposed objectformat extension means parsing any object data is likely to encounter errors) - this is a sign that whatever tool wrote the extension field is broken. We may be better off notifying immediately and forcefully so that such tools don't even appear to work accidentally. The only downside is that fixing the situation is a little tricky, because programs like "git config" won't want to work with the repository. But: git config --file=.git/config core.repositoryformatversion 1 should still suffice. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>