Skip to main content

Browse the archive

swh:1:snp:6df5a50b8107b6bbe1e51d0239d816a7503c536a
sort by:
Revision Author Date Message Commit Date
2c04f63 Junio C Hamano 05 June 2017, 00:05:38 UTC Git 2.13.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 June 2017, 00:05:38 UTC
478d3c3 Junio C Hamano 05 June 2017, 00:03:23 UTC Merge branch 'ah/doc-rev-parse-short-default' into maint Doc update. * ah/doc-rev-parse-short-default: doc: rewrite description for rev-parse --short 05 June 2017, 00:03:23 UTC
f166aab Junio C Hamano 05 June 2017, 00:03:22 UTC Merge branch 'ah/doc-filter-branch-export-env' into maint Docfix. * ah/doc-filter-branch-export-env: doc: filter-branch does not require re-export of vars 05 June 2017, 00:03:22 UTC
e06b421 Junio C Hamano 05 June 2017, 00:03:22 UTC Merge branch 'sd/t3200-typofix' into maint Test fix. * sd/t3200-typofix: branch test: fix invalid config key access 05 June 2017, 00:03:22 UTC
2ed824b Junio C Hamano 05 June 2017, 00:03:21 UTC Merge branch 'sb/t5531-update-desc' into maint The description strings for a few tests have been updated. * sb/t5531-update-desc: t5531: fix test description 05 June 2017, 00:03:21 UTC
bba1c2b Junio C Hamano 05 June 2017, 00:03:20 UTC Merge branch 'ah/doc-pretty-format-fix' into maint Documentation fix. * ah/doc-pretty-format-fix: Documentation: fix formatting typo in pretty-formats.txt 05 June 2017, 00:03:20 UTC
04dad24 Junio C Hamano 05 June 2017, 00:03:19 UTC Merge branch 'ah/doc-interpret-trailers-ifexists' into maint Documentation fix. * ah/doc-interpret-trailers-ifexists: Documentation: fix reference to ifExists for interpret-trailers 05 June 2017, 00:03:19 UTC
0d86bbd Junio C Hamano 05 June 2017, 00:03:18 UTC Merge branch 'ab/ref-filter-no-contains' into maint Doc update to a recent topic. * ab/ref-filter-no-contains: tag: duplicate mention of --contains should mention --no-contains 05 June 2017, 00:03:18 UTC
b8a4652 Junio C Hamano 05 June 2017, 00:03:17 UTC Merge branch 'sg/core-filemode-doc-typofix' into maint * sg/core-filemode-doc-typofix: docs/config.txt: fix indefinite article in core.fileMode description 05 June 2017, 00:03:17 UTC
86799c1 Junio C Hamano 05 June 2017, 00:03:16 UTC Merge branch 'tb/dedup-crlf-tests' into maint * tb/dedup-crlf-tests: t0027: tests are not expensive; remove t0025 05 June 2017, 00:03:16 UTC
9a73c95 Junio C Hamano 05 June 2017, 00:03:16 UTC Merge branch 'jn/credential-doc-on-clear' into maint Doc update. * jn/credential-doc-on-clear: credential doc: make multiple-helper behavior more prominent 05 June 2017, 00:03:16 UTC
7dab7c5 Junio C Hamano 05 June 2017, 00:03:15 UTC Merge branch 'jk/url-insteadof-config' into maint The interaction of "url.*.insteadOf" and custom URL scheme's whitelisting is now documented better. * jk/url-insteadof-config: docs/config: mention protocol implications of url.insteadOf 05 June 2017, 00:03:15 UTC
f72e075 Junio C Hamano 05 June 2017, 00:03:15 UTC Merge branch 'jk/unbreak-am-h' into maint "git am -h" triggered a BUG(). * jk/unbreak-am-h: am: handle "-h" argument earlier 05 June 2017, 00:03:15 UTC
d0506fc Junio C Hamano 05 June 2017, 00:03:15 UTC Merge branch 'ab/sha1dc-maint' into maint The "collision detecting" SHA-1 implementation shipped with 2.13 was quite broken on some big-endian platforms and/or platforms that do not like unaligned fetches. Update to the upstream code which has already fixed these issues. * ab/sha1dc-maint: sha1dc: update from upstream 05 June 2017, 00:03:15 UTC
e6f80ae Junio C Hamano 05 June 2017, 00:03:15 UTC Merge branch 'js/bs-is-a-dir-sep-on-windows' into maint "foo\bar\baz" in "git fetch foo\bar\baz", even though there is no slashes in it, cannot be a nickname for a remote on Windows, as that is likely to be a pathname on a local filesystem. * js/bs-is-a-dir-sep-on-windows: Windows: do not treat a path with backslashes as a remote's nick name mingw.h: permit arguments with side effects for is_dir_sep 05 June 2017, 00:03:15 UTC
a07148d Junio C Hamano 05 June 2017, 00:03:14 UTC Merge branch 'jk/alternate-ref-optim' into maint A test allowed both "git push" and "git receive-pack" on the other end write their traces into the same file. This is OK on platforms that allows atomically appending to a file opened with O_APPEND, but on other platforms led to a mangled output, causing intermittent test failures. This has been fixed by disabling traces from "receive-pack" in the test. * jk/alternate-ref-optim: t5400: avoid concurrent writes into a trace file 05 June 2017, 00:03:14 UTC
00c0e40 Junio C Hamano 05 June 2017, 00:03:13 UTC Merge branch 'bm/interpret-trailers-cut-line-is-eom' into maint "git interpret-trailers", when used as GIT_EDITOR for "git commit -v", looked for and appended to a trailer block at the very end, i.e. at the end of the "diff" output. The command has been corrected to pay attention to the cut-mark line "commit -v" adds to the buffer---the real trailer block should appear just before it. * bm/interpret-trailers-cut-line-is-eom: interpret-trailers: honor the cut line 05 June 2017, 00:03:13 UTC
fd8567c Junio C Hamano 05 June 2017, 00:03:13 UTC Merge branch 'kn/ref-filter-branch-list' into maint "git for-each-ref --format=..." with %(HEAD) in the format used to resolve the HEAD symref as many times as it had processed refs, which was wasteful, and "git branch" shared the same problem. * kn/ref-filter-branch-list: ref-filter: resolve HEAD when parsing %(HEAD) atom 05 June 2017, 00:03:13 UTC
a207ad7 Junio C Hamano 05 June 2017, 00:03:12 UTC Merge branch 'rs/checkout-am-fix-unborn' into maint A few codepaths in "checkout" and "am" working on an unborn branch tried to access an uninitialized piece of memory. * rs/checkout-am-fix-unborn: am: check return value of resolve_refdup before using hash checkout: check return value of resolve_refdup before using hash 05 June 2017, 00:03:12 UTC
c8c3321 Junio C Hamano 05 June 2017, 00:03:11 UTC Merge branch 'jn/clone-add-empty-config-from-command-line' into maint "git clone --config var=val" is a way to populate the per-repository configuration file of the new repository, but it did not work well when val is an empty string. This has been fixed. * jn/clone-add-empty-config-from-command-line: clone: handle empty config values in -c 05 June 2017, 00:03:11 UTC
b19174e Junio C Hamano 05 June 2017, 00:03:10 UTC Merge branch 'ab/c-translators-comment-style' into maint Update the C style recommendation for notes for translators, as recent versions of gettext tools can work with our style of multi-line comments. * ab/c-translators-comment-style: C style: use standard style for "TRANSLATORS" comments 05 June 2017, 00:03:10 UTC
916a338 Junio C Hamano 05 June 2017, 00:03:10 UTC Merge branch 'ls/travis-doc-asciidoctor' into maint Travis CI gained a task to format the documentation with both AsciiDoc and AsciiDoctor. * ls/travis-doc-asciidoctor: travis-ci: check AsciiDoc/AsciiDoctor stderr output travis-ci: unset compiler for jobs that do not need one travis-ci: parallelize documentation build travis-ci: build documentation with AsciiDoc and Asciidoctor 05 June 2017, 00:03:10 UTC
e215bd9 Junio C Hamano 04 June 2017, 01:25:42 UTC Prepare for 2.13.1; more topics to follow Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 June 2017, 01:29:06 UTC
5ecbaaf Junio C Hamano 04 June 2017, 01:21:07 UTC Merge branch 'tg/stash-push-fixup' into maint The shell completion script (in contrib/) learned "git stash" has a new "push" subcommand. * tg/stash-push-fixup: completion: add git stash push 04 June 2017, 01:21:08 UTC
b522c33 Junio C Hamano 04 June 2017, 01:21:07 UTC Merge branch 'km/log-showsignature-doc' into maint Doc update. * km/log-showsignature-doc: config.txt: add an entry for log.showSignature 04 June 2017, 01:21:07 UTC
e2ae5ec Junio C Hamano 04 June 2017, 01:21:06 UTC Merge branch 'jt/use-trailer-api-in-commands' into maint "git cherry-pick" and other uses of the sequencer machinery mishandled a trailer block whose last line is an incomplete line. This has been fixed so that an additional sign-off etc. are added after completing the existing incomplete line. * jt/use-trailer-api-in-commands: sequencer: add newline before adding footers 04 June 2017, 01:21:06 UTC
058d655 Junio C Hamano 04 June 2017, 01:21:05 UTC Merge branch 'jt/push-options-doc' into maint The receive-pack program now makes sure that the push certificate records the same set of push options used for pushing. * jt/push-options-doc: receive-pack: verify push options in cert docs: correct receive.advertisePushOptions default 04 June 2017, 01:21:05 UTC
34bbe2e Junio C Hamano 04 June 2017, 01:21:04 UTC Merge branch 'js/plug-leaks' into maint Fix memory leaks pointed out by Coverity (and people). * js/plug-leaks: (26 commits) checkout: fix memory leak submodule_uses_worktrees(): plug memory leak show_worktree(): plug memory leak name-rev: avoid leaking memory in the `deref` case remote: plug memory leak in match_explicit() add_reflog_for_walk: avoid memory leak shallow: avoid memory leak line-log: avoid memory leak receive-pack: plug memory leak in update() fast-export: avoid leaking memory in handle_tag() mktree: plug memory leaks reported by Coverity pack-redundant: plug memory leak setup_discovered_git_dir(): plug memory leak setup_bare_git_dir(): help static analysis split_commit_in_progress(): simplify & fix memory leak checkout: fix memory leak cat-file: fix memory leak mailinfo & mailsplit: check for EOF while parsing status: close file descriptor after reading git-rebase-todo difftool: address a couple of resource/memory leaks ... 04 June 2017, 01:21:04 UTC
7ba4fa5 Junio C Hamano 04 June 2017, 01:21:04 UTC Merge branch 'js/eol-on-ourselves' into maint Make sure our tests would pass when the sources are checked out with "platform native" line ending convention by default on Windows. Some "text" files out tests use and the test scripts themselves that are meant to be run with /bin/sh, ought to be checked out with eol=LF even on Windows. * js/eol-on-ourselves: t4051: mark supporting files as requiring LF-only line endings Fix the remaining tests that failed with core.autocrlf=true t3901: move supporting files into t/t3901/ completion: mark bash script as LF-only git-new-workdir: mark script as LF-only Fix build with core.autocrlf=true 04 June 2017, 01:21:04 UTC
970fb22 Junio C Hamano 04 June 2017, 01:21:04 UTC Merge branch 'jk/update-links-in-docs' into maint A few http:// links that are redirected to https:// in the documentation have been updated to https:// links. * jk/update-links-in-docs: doc: use https links to Wikipedia to avoid http redirects 04 June 2017, 01:21:04 UTC
8d958b9 Junio C Hamano 04 June 2017, 01:21:03 UTC Merge branch 'jk/ignore-broken-tags-when-ignoring-missing-links' into maint Tag objects, which are not reachable from any ref, that point at missing objects were mishandled by "git gc" and friends (they should silently be ignored instead) * jk/ignore-broken-tags-when-ignoring-missing-links: revision.c: ignore broken tags with ignore_missing_links 04 June 2017, 01:21:03 UTC
aa5439d Junio C Hamano 04 June 2017, 01:21:02 UTC Merge branch 'jk/doc-config-include' into maint Clarify documentation for include.path and includeIf.<condition>.path configuration variables. * jk/doc-config-include: docs/config: consistify include.path examples docs/config: avoid the term "expand" for includes docs/config: give a relative includeIf example docs/config: clarify include/includeIf relationship 04 June 2017, 01:21:02 UTC
f305016 Junio C Hamano 04 June 2017, 01:21:02 UTC Merge branch 'jk/disable-pack-reuse-when-broken' into maint "pack-objects" can stream a slice of an existing packfile out when the pack bitmap can tell that the reachable objects are all needed in the output, without inspecting individual objects. This strategy however would not work well when "--local" and other options are in use, and need to be disabled. * jk/disable-pack-reuse-when-broken: t5310: fix "; do" style pack-objects: disable pack reuse for object-selection options 04 June 2017, 01:21:02 UTC
70d19a4 Junio C Hamano 04 June 2017, 01:21:01 UTC Merge branch 'jk/am-leakfix' into maint The codepath in "git am" that is used when running "git rebase" leaked memory held for the log message of the commits being rebased. * jk/am-leakfix: am: shorten ident_split variable name in get_commit_info() am: simplify allocations in get_commit_info() am: fix commit buffer leak in get_commit_info() 04 June 2017, 01:21:01 UTC
8a17b25 Junio C Hamano 04 June 2017, 01:21:00 UTC Merge branch 'jc/read-tree-empty-with-m' into maint "git read-tree -m" (no tree-ish) gave a nonsense suggestion "use --empty if you want to clear the index". With "-m", such a request will still fail anyway, as you'd need to name at least one tree-ish to be merged. * jc/read-tree-empty-with-m: read-tree: "read-tree -m --empty" does not make sense 04 June 2017, 01:21:00 UTC
34a75cc Junio C Hamano 04 June 2017, 01:20:59 UTC Merge branch 'jc/apply-fix-mismerge' into maint Mismerge fix. * jc/apply-fix-mismerge: apply.c: fix whitespace-only mismerge 04 June 2017, 01:20:59 UTC
0501b7e Junio C Hamano 04 June 2017, 01:20:58 UTC Merge branch 'ja/do-not-ask-needless-questions' into maint Git sometimes gives an advice in a rhetorical question that does not require an answer, which can confuse new users and non native speakers. Attempt to rephrase them. * ja/do-not-ask-needless-questions: git-filter-branch: be more direct in an error message read-tree -m: make error message for merging 0 trees less smart aleck usability: don't ask questions if no reply is required 04 June 2017, 01:20:59 UTC
c95f0d2 Junio C Hamano 04 June 2017, 01:20:58 UTC Merge branch 'bw/submodule-with-bs-path' into maint A hotfix to a topic that is already in v2.13. * bw/submodule-with-bs-path: t7400: add !CYGWIN prerequisite to 'add with \\ in path' 04 June 2017, 01:20:58 UTC
fb11de9 Junio C Hamano 04 June 2017, 01:20:57 UTC Merge branch 'ah/log-decorate-default-to-auto' into maint Setting "log.decorate=false" in the configuration file did not take effect in v2.13, which has been corrected. * ah/log-decorate-default-to-auto: builtin/log: honor log.decorate 04 June 2017, 01:20:57 UTC
6c940eb Junio C Hamano 04 June 2017, 01:20:56 UTC Merge branch 'ab/fix-poison-tests' into maint Update tests to pass under GETTEXT_POISON (a mechanism to ensure that output strings that should not be translated are not translated by mistake), and tell TravisCI to run them. * ab/fix-poison-tests: travis-ci: add job to run tests with GETTEXT_POISON travis-ci: setup "prove cache" in "script" step tests: fix tests broken under GETTEXT_POISON=YesPlease 04 June 2017, 01:20:56 UTC
16b4a48 Junio C Hamano 04 June 2017, 01:20:56 UTC Merge branch 'ab/doc-replace-gmane-links' into maint The Web interface to gmane news archive is long gone, even though the articles are still accessible via NTTP. Replace the links with ones to public-inbox.org. Because their message identification is based on the actual message-id, it is likely that it will be easier to migrate away from it if/when necessary. * ab/doc-replace-gmane-links: doc: replace more gmane links doc: replace a couple of broken gmane links 04 June 2017, 01:20:56 UTC
9102f42 Junio C Hamano 04 June 2017, 01:20:56 UTC Merge branch 'ab/aix-needs-compat-regex' into maint Build fix. * ab/aix-needs-compat-regex: config.mak.uname: set NO_REGEX=NeedsStartEnd on AIX 04 June 2017, 01:20:56 UTC
19a23d6 Junio C Hamano 04 June 2017, 01:20:55 UTC Merge branch 'pw/rebase-i-regression-fix' into maint Just the first one of three? new tests that follows up a regression fix. * pw/rebase-i-regression-fix: rebase -i: add missing newline to end of message rebase -i: silence stash apply rebase -i: fix reflog message 04 June 2017, 01:20:55 UTC
fb87327 Andreas Heiduk 31 May 2017, 21:39:29 UTC doc: rewrite description for rev-parse --short `git rev-parse --short` is not a generic modifier but just a variant of `--verify` and considers the given length only as a suggestion to ensure uniqueness. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2017, 01:37:42 UTC
2c9a2ae Jeff King 31 May 2017, 05:18:04 UTC docs/config: mention protocol implications of url.insteadOf If a URL rewrite switches the protocol to something nonstandard (like "persistent-https" for "https"), the user may be bitten by the fact that the default protocol restrictions are different between the two. Let's drop a note in insteadOf that points the user in the right direction. It would be nice if we could make this work out of the box, but we can't without knowing the security implications of the user's rewrite. Only the documentation for a particular remote helper can advise one way or the other. Since we do include the persistent-https helper in contrib/ (and since it was the helper in the real-world case that inspired that patch), let's also drop a note there. Suggested-by: Elliott Cable <me@ell.io> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2017, 01:07:10 UTC
66f5f6d Ævar Arnfjörð Bjarmason 11 May 2017, 21:20:12 UTC C style: use standard style for "TRANSLATORS" comments Change all the "TRANSLATORS: [...]" comments in the C code to use the regular Git coding style, and amend the style guide so that the example there uses that style. This custom style was necessary back in 2010 when the gettext support was initially added, and was subsequently documented in commit cbcfd4e3ea ("i18n: mention "TRANSLATORS:" marker in Documentation/CodingGuidelines", 2014-04-18). GNU xgettext hasn't had the parsing limitation that necessitated this exception for almost 3 years. Since its 0.19 release on 2014-06-02 it's been able to recognize TRANSLATOR comments in the standard Git comment syntax[1]. Usually we'd like to keep compatibility with software that's that young, but in this case literally the only person who needs to be using a gettext newer than 3 years old is Jiang Xin (the only person who runs & commits "make pot" results), so I think in this case we can make an exception. This xgettext parsing feature was added after a thread on the Git mailing list[2] which continued on the bug-gettext[3] list, but we never subsequently changed our style & styleguide, do so. There are already longstanding changes in git that use the standard comment style & have their TRANSLATORS comments extracted properly without getting the literal "*"'s mixed up in the text, as would happen before xgettext 0.19. Commit 7ff2683253 ("builtin-am: implement -i/--interactive", 2015-08-04) added one such comment, which in commit df0617bfa7 ("l10n: git.pot: v2.6.0 round 1 (123 new, 41 removed)", 2015-09-05) got picked up in the po/git.pot file with the right format, showing that Jiang already runs a modern xgettext. The xgettext parser does not handle the sort of non-standard comment style that I'm amending here in sequencer.c, but that isn't standard Git comment syntax anyway. With this change to sequencer.c & "make pot" the comment in the pot file is now correct: #. TRANSLATORS: %s will be "revert", "cherry-pick" or -#. * "rebase -i". +#. "rebase -i". 1. http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=10af7fe6bd 2. <2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com> (https://public-inbox.org/git/2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com/) 3. https://lists.gnu.org/archive/html/bug-gettext/2014-04/msg00016.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 May 2017, 23:01:42 UTC
f3a2fff Jeff King 30 May 2017, 05:11:23 UTC am: handle "-h" argument earlier If the user provides "-h" on the command line, then our parse_options() invocation will show a usage message and quit. But if "-h" is the only argument, the git wrapper behaves specially: it ignores our RUN_SETUP flag and calls cmd_am() without having done repository setup at all. This is due to 99caeed05 (Let 'git <command> -h' show usage without a git dir, 2009-11-09). Before cmd_am() calls parse_options(), though, it runs a few other setup functions. One of these is am_state_init(), which uses git_pathdup() to set up the default rebase-apply path. But calling git_pathdup() when we haven't done repository setup will fall back to using ".git". That's mostly harmless (since we won't use the value anyway), but is forbidden since b1ef400eec ("setup_git_env: avoid blind fall-back to ".git"", 2016-10-20), and we now BUG(). We can't easily move that setup to after the parse_options() call; the point is to set up defaults that are overwritten by the option parsing. Instead, we'll detect the "-h" case early and show the usage then. This matches the behavior of other builtins which have a similar setup-ordering issue (e.g., git-branch). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 May 2017, 05:39:47 UTC
b8f354f Sahil Dua 28 May 2017, 17:12:16 UTC branch test: fix invalid config key access Fixes the test by changing "branch.s/s/dummy" to "branch.s/s.dummy" which is the right way of accessing config key "branch.s/s.dummy". Purpose of this test is to confirm that this key doesn't exist after the branch "s/s" has been renamed to "s". Earlier it was trying to access invalid config key and hence was getting an error. However, this wasn't caught because we were expecting the command to fail for other reason as mentioned above. Signed-off-by: Sahil Dua <sahildua2305@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 May 2017, 04:18:43 UTC
ba746ff Andreas Heiduk 26 May 2017, 17:36:54 UTC doc: filter-branch does not require re-export of vars The function `set_ident` in `filter-branch` exported the variables GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL|DATE) at least since 6f6826c52b in 2007. Therefore the filter scripts don't need to re-eport them again. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 May 2017, 23:53:38 UTC
449456a SZEDER Gábor 25 May 2017, 23:20:46 UTC docs/config.txt: fix indefinite article in core.fileMode description Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 May 2017, 03:21:07 UTC
d9244ec Johannes Sixt 25 May 2017, 12:00:13 UTC Windows: do not treat a path with backslashes as a remote's nick name On Windows, the remote repository name in, e.g., `git fetch foo\bar` is clearly not a nickname for a configured remote repository. However, the function valid_remote_nick() does not account for backslashes. Use is_dir_sep() to check for both slashes and backslashes on Windows. This was discovered while playing with Duy's patches that warn after fopen() failures. The functions that read the branches and remotes files are protected by a valid_remote_nick() check. Without this change, a Windows style absolute path is incorrectly regarded as nickname and is concatenated to a prefix and used with fopen(). This triggers warnings because a colon in a path name is not allowed: C:\Temp\gittest>git fetch C:\Temp\gittest warning: unable to access '.git/remotes/C:\Temp\gittest': Invalid argument warning: unable to access '.git/branches/C:\Temp\gittest': Invalid argument From C:\Temp\gittest * branch HEAD -> FETCH_HEAD Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 May 2017, 23:05:32 UTC
80f4cd8 Ævar Arnfjörð Bjarmason 15 May 2017, 12:23:31 UTC tag: duplicate mention of --contains should mention --no-contains Fix a duplicate mention of --contains in the SYNOPSIS to mention --no-contains. This fixes an error introduced in my commit ac3f5a3468 ("ref-filter: add --no-contains option to tag/branch/for-each-ref", 2017-03-24). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 May 2017, 12:54:05 UTC
e20b5b5 Johannes Sixt 22 May 2017, 18:58:32 UTC mingw.h: permit arguments with side effects for is_dir_sep Taking git-compat-util.h's cue (which uses an inline function to back is_dir_sep()), let's use an inline function to back also the Windows version of is_dir_sep(). This avoids problems when calling the function with arguments that do more than just provide a single character, e.g. incrementing a pointer. Example: is_dir_sep(*p++) Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 May 2017, 12:42:14 UTC
fc7a5ed Andreas Heiduk 22 May 2017, 20:59:58 UTC Documentation: fix formatting typo in pretty-formats.txt A missing space messed up formatting of the `%(trailers)` format. Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 May 2017, 05:46:26 UTC
b275da8 Andreas Heiduk 22 May 2017, 19:45:33 UTC Documentation: fix reference to ifExists for interpret-trailers The manual for "git interpret-trailers" mentioned a non-existing literal `overwrite` for its config option `trailer.ifexists`. The correct name for that choice is `replace`. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 May 2017, 05:18:26 UTC
7e95fcb Stefan Beller 22 May 2017, 19:01:14 UTC t5531: fix test description The description of the test was not enclosed in single quotes, which broke the coloring scheme that I am used to. Upon closer inspection the test is good, but the description is a bit vague. So extend the description of the first test. While at it align the description of the file to match what we actually test in the file. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 May 2017, 05:16:42 UTC
a010391 Ævar Arnfjörð Bjarmason 20 May 2017, 11:54:28 UTC sha1dc: update from upstream Update sha1dc from the latest version by the upstream maintainer[1]. This version includes a commit of mine which allows for replacing the local modifications done to the upstream files in git.git with macro definitions to monkeypatch it in place. It also brings in a change[2] upstream made for the breakage 2.13.0 introduced on SPARC and other platforms that forbid unaligned access[3]. This means that the code customizations done since the initial import in commit 28dc98e343 ("sha1dc: add collision-detecting sha1 implementation", 2017-03-16) can be done purely via Makefile definitions and by including the content of our own sha1dc_git.[ch] in sha1dc/sha1.c via a macro. 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/cc465543b310e5f59a1d534381690052e8509b22 2. https://github.com/cr-marcstevens/sha1collisiondetection/commit/33a694a9ee1b79c24be45f9eab5ac0e1aeeaf271 3. "Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease being on by default" (https://public-inbox.org/git/CACBZZX6nmKK8af0-UpjCKWV4R+hV-uk2xWXVA5U+_UQ3VXU03g@mail.gmail.com/) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 May 2017, 01:20:46 UTC
a3ba6bf Jeff King 20 May 2017, 08:30:25 UTC revision.c: ignore broken tags with ignore_missing_links When peeling a tag for prepare_revision_walk(), we do not respect the ignore_missing_links flag. This can lead to a bogus error when pack-objects walks the possibly-broken unreachable-but-recent part of the object graph. The other link-following all happens via traverse_commit_list(), which explains why this case was missed. And our tests covered only broken links from commits. Let's be more comprehensive and cover broken tree entries (which do work) and tags (which shows off this bug). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2017, 09:32:58 UTC
ba4dce7 Kyle Meyer 19 May 2017, 02:44:51 UTC config.txt: add an entry for log.showSignature The configuration variable log.showSignature is mentioned in git-log's manpage. Document it in git-config's manpage as well. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2017, 09:32:17 UTC
d096d7f Phillip Wood 19 May 2017, 14:32:48 UTC rebase -i: add missing newline to end of message The message that's printed when auto-stashed changes are successfully restored was missing '\n' at the end. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2017, 09:25:20 UTC
79a6226 Phillip Wood 18 May 2017, 10:02:33 UTC rebase -i: silence stash apply The shell version of rebase -i silences the status output from 'git stash apply' when restoring the autostashed changes. The C version does not. Having the output from git stash apply on the screen is distracting as it makes it difficult to find the message from git rebase saying that the rebase succeeded. Also the status information that git stash prints talks about looking in .git/rebase-merge/done to see which commits have been applied. As .git/rebase-merge is removed shortly after the message is printed before rebase -i exits this is confusing. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2017, 09:24:28 UTC
4ab867b Phillip Wood 18 May 2017, 10:02:32 UTC rebase -i: fix reflog message When rebase -i was converted to C a bug was introduced into the code that creates the reflog message. Instead of saying rebase -i (finish): <head-name> onto <onto> it says rebase -i (finish): <head-name> onto <orig-head><onto> as the strbuf is not reset between reading the value of <orig-head> and <onto>. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2017, 09:24:25 UTC
613a0e5 Jeff King 19 May 2017, 06:12:12 UTC ref-filter: resolve HEAD when parsing %(HEAD) atom If the user asks to display (or sort by) the %(HEAD) atom, ref-filter has to compare each refname to the value of HEAD. We do so by resolving HEAD fresh when calling populate_value() on each ref. If there are a large number of refs, this can have a measurable impact on runtime. Instead, let's resolve HEAD once when we realize we need the %(HEAD) atom, allowing us to do a simple string comparison for each ref. On a repository with 3000 branches (high, but an actual example found in the wild) this drops the best-of-five time to run "git branch >/dev/null" from 59ms to 48ms (~20% savings). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2017, 09:18:45 UTC
d76650b Brian Malehorn 16 May 2017, 06:06:49 UTC interpret-trailers: honor the cut line If a commit message is edited with the "verbose" option, the buffer will have a cut line and diff after the log message, like so: my subject # ------------------------ >8 ------------------------ # Do not touch the line above. # Everything below will be removed. diff --git a/foo.txt b/foo.txt index 5716ca5..7601807 100644 --- a/foo.txt +++ b/foo.txt @@ -1 +1 @@ -bar +baz "git interpret-trailers" is unaware of the cut line, and assumes the trailer block would be at the end of the whole thing. This can easily be seen with: $ GIT_EDITOR='git interpret-trailers --in-place --trailer Acked-by:me' \ git commit --amend -v Teach "git interpret-trailers" to notice the cut-line and ignore the remainder of the input when looking for a place to add new trailer block. This makes it consistent with how "git commit -v -s" inserts a new Signed-off-by: line. This can be done by the same logic as the existing helper function, wt_status_truncate_message_at_cut_line(), uses, but it wants the caller to pass a strbuf to it. Because the function ignore_non_trailer() used by the command takes a <pointer, length> pair, not a strbuf, steal the logic from wt_status_truncate_message_at_cut_line() to create a new wt_status_locate_end() helper function that takes <pointer, length> pair, and make ignore_non_trailer() call it to help "interpret-trailers". Since there is only one caller of wt_status_truncate_message_at_cut_line() in cmd_commit(), rewrite it to call wt_status_locate_end() helper instead and remove the old helper that no longer has any caller. Signed-off-by: Brian Malehorn <bmalehorn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 May 2017, 06:00:48 UTC
71406ed Jeff King 18 May 2017, 05:02:09 UTC t5400: avoid concurrent writes into a trace file One test in t5400 examines the packet exchange between git-push and git-receive-pack. The latter inherits the GIT_TRACE_PACKET environment variable, so that both processes dump trace data into the same file concurrently. This should not be a problem because the trace file is opened with O_APPEND. On Windows, however, O_APPEND is not atomic as it should be: it is emulated as lseek(SEEK_END) followed by write(). For this reason, the test is unreliable: it can happen that one process overwrites a line that was just written by the other process. As a consequence, the test sometimes does not find one or another line that is expected (and it is also successful occasionally). The test case is actually only interested in the output of git-push. To ensure that only git-push writes to the trace file, override the receive-pack command such that it does not even open the trace file. Reported-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 May 2017, 05:09:23 UTC
3851e44 Thomas Gummerer 16 May 2017, 19:59:45 UTC completion: add git stash push When introducing git stash push in f5727e26e4 ("stash: introduce push verb", 2017-02-19), I forgot to add it to the completion code. Add it now. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 May 2017, 03:15:56 UTC
5e68729 Sven Strickroth 13 May 2017, 09:54:51 UTC doc: use https links to Wikipedia to avoid http redirects Signed-off-by: Sven Strickroth <email@cs-ware.de> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 May 2017, 04:04:54 UTC
c74271a brian m. carlson 14 May 2017, 18:00:58 UTC builtin/log: honor log.decorate The recent change that introduced autodecorating of refs accidentally broke the ability of users to set log.decorate = false to override it. When the git_log_config was traversed a second time with an option other than log.decorate, the decoration style would be set to the automatic style, even if the user had already overridden it. Instead of setting the option in config parsing, set it in init_log_defaults instead. Add a test for this case. The actual additional config option doesn't matter, but it needs to be something not already set in the configuration file. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Alex Henrie <alexhenrie24@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 May 2017, 02:33:19 UTC
6963893 Jean-Noel Avila 11 May 2017, 12:06:34 UTC git-filter-branch: be more direct in an error message git-filter-branch requires the specification of a branch by one way or another. If no branch appears to have been specified, we know the user got the usage wrong but we don't know what they were trying to do --- e.g. maybe they specified the ref to rewrite but in the wrong place. In this case, just state that the branch specification is missing. Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2017, 06:27:10 UTC
9932242 Jean-Noel Avila 11 May 2017, 12:06:33 UTC read-tree -m: make error message for merging 0 trees less smart aleck "git read-tree -m" requires a tree argument to name the tree to be merged in. Git uses a cutesy error message to say so and why: $ git read-tree -m warning: read-tree: emptying the index with no arguments is deprecated; use --empty fatal: just how do you expect me to merge 0 trees? $ git read-tree -m --empty fatal: just how do you expect me to merge 0 trees? When lucky, that could produce an ah-hah moment for the user, but it's more likely to irritate and distract them. Instead, tell the user plainly that the tree argument is required. Also document this requirement in the git-read-tree(1) manpage where there is room to explain it in a more straightforward way. Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2017, 06:23:39 UTC
6c48686 Jean-Noel Avila 11 May 2017, 12:06:32 UTC usability: don't ask questions if no reply is required There has been a bug report by a corporate user that stated that "spelling mistake of stash followed by a yes prints character 'y' infinite times." This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the following: git: 'stahs' is not a git command. See 'git --help'. Did you mean this? stash and then exits. The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished. The user was unlucky enough that it was the command he was looking for, and replied "yes" on the command line, effectively launching the `yes` program. The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply that they won't handle indeed. That's a source of confusion on UX level. To improve the general usability of the Git suite, the following rule was applied: if the sentence * appears in a non-interactive session * is printed last before exit * is a question addressing the user ("you") the sentence is turned into affirmative and proposes the option. The basic rewording of the question sentences has been extended to other spots found in the source. Requested at https://github.com/git/git-scm.com/issues/999 by rpai1 Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2017, 06:18:13 UTC
ce933eb Jeff King 11 May 2017, 09:14:30 UTC docs/config: consistify include.path examples Most of the include examples use "foo.inc", but some use "foo". Since the string of examples are meant to show variations and how they differ, it's a good idea to change only one thing at a time. The filename differences are not relevant to what we're trying to show. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2017, 01:06:59 UTC
a076df2 Jeff King 11 May 2017, 09:13:04 UTC docs/config: avoid the term "expand" for includes Using the word "expand" to refer to including the contents of another config file isn't really accurate, since it's a verbatim insertion. And it can cause confusion with the expanding of the path itself via things like "~". Let's clarify when we are referring to the contents versus the filename, and use appropriate verbs in each case. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2017, 01:06:58 UTC
994cd6c Jeff King 11 May 2017, 09:11:06 UTC docs/config: give a relative includeIf example The changes in the previous commit hopefully clarify that the evaluation of an include "path" variable is the same no matter if it's in a conditional section or not. But since this question came up on the list, let's add an example that makes it obvious. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2017, 01:06:58 UTC
9d71d94 Jeff King 11 May 2017, 09:10:47 UTC docs/config: clarify include/includeIf relationship The "includeIf" directives behave exactly like include ones, except they only kick in when the conditional is true. That was mentioned in the "conditional" section, but let's make it more clear for the whole "includes" section, since people don't necessarily read the documentation top to bottom. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2017, 01:06:56 UTC
b8e188f Lars Schneider 05 May 2017, 15:40:53 UTC travis-ci: add job to run tests with GETTEXT_POISON Add a job to run Git tests with GETTEXT_POISON. In this job we don't run the git-p4, git-svn, and HTTPD tests to save resources/time (those tests are already executed in other jobs). Since we don't run these tests, we can also skip the "before_install" step (which would install the necessary dependencies) with an empty override. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 May 2017, 09:44:54 UTC
3ae72a3 Lars Schneider 05 May 2017, 15:40:52 UTC travis-ci: setup "prove cache" in "script" step The command that made the "prove cache" persistent across builds was executed in the "before_install" step. Consequently, every job that wanted to make use of the cache had to run this step. The "prove cache" is only used in the "script" step for the "make test" command. Therefore, we should configure the "prove cache" in this step. This change is useful for a subsequent patch that adds a job which does not need the "before_install" step but wants to run the "script" step to execute the tests. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 May 2017, 09:44:54 UTC
0d75bfe Ævar Arnfjörð Bjarmason 05 May 2017, 18:19:32 UTC tests: fix tests broken under GETTEXT_POISON=YesPlease The GETTEXT_POISON=YesPlease compile-time testing option added in my bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) has been slowly bitrotting as strings have been marked for translation, and new tests have been added without running it. I brought this up on the list ("[BUG] test suite broken with GETTEXT_POISON=YesPlease", [1]) asking whether this mode was useful at all anymore. At least one person occasionally uses it, and Lars Schneider offered to change one of the the Travis builds to run in this mode, so fix up the failing ones. My test setup runs most of the tests, with the notable exception of skipping all the p4 tests, so it's possible that there's still some lurking regressions I haven't fixed. 1. <CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 May 2017, 09:44:38 UTC
b9b10d3 Junio C Hamano 11 May 2017, 04:31:54 UTC read-tree: "read-tree -m --empty" does not make sense fb1bb965 ("read-tree: deprecate syntax without tree-ish args", 2010-09-10) wanted to deprecate "git read-tree" without any tree, which used to be the way to empty the index, and encourage use of "git read-tree --empty" instead. However, when used with "-m", "--empty" does not make any sense, either, simply because merging 0 trees will result in a different error anyway. Omit the deprecation warning and let the code to emit real error message diagnose the error. Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 May 2017, 04:42:17 UTC
c8f7c8b Torsten Bögershausen 10 May 2017, 14:06:19 UTC t0027: tests are not expensive; remove t0025 The purpose of t0027 is to test all CRLF related conversions at "git checkout" and "git add". Running t0027 under Git for Windows takes 3-4 minutes, so the whole script had been marked as "EXPENSIVE". However, the "Git for Windows" fork overrides this since 2014: "t0027 is marked expensive, but really, for MinGW we want to run these tests always." The test seems not to be expensive on other platforms at all: it takes less than 14 seconds under Linux, and 63 seconds under Mac Os X, and this is more or less the same with a SSD or a spinning disk. So let's drop the "EXPENSIVE" prereq. While at it, retire t0025; recent "stress" tests show that t0025 is flaky, reported by Lars Schneider <larsxschneider@gmail.com>, but all tests in t0025 are covered by t0027 already. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 May 2017, 02:15:08 UTC
2779f66 Johannes Schindelin 09 May 2017, 12:54:32 UTC t4051: mark supporting files as requiring LF-only line endings The test t4051-diff-function-context.sh passes on Linux when core.autocrlf=true even without marking its support files as LF-only, but they fail when core.autocrlf=true in Git for Windows' SDK. The reason is that `grep ... >file.c.new` will keep CR/LF line endings on Linux (obviously treating CRs as if they were regular characters), but will be converted to LF-only line endings with MSYS2's grep that is used in Git for Windows. As we do not want to validate the way the available `grep` works, let's just mark the input as LF-only and move on. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2017, 04:32:51 UTC
614f4f0 Johannes Schindelin 09 May 2017, 12:54:27 UTC Fix the remaining tests that failed with core.autocrlf=true The test suite is mainly developed on Linux and MacOSX, which is the reason that nobody thought to mark files as LF-only as needed. The symptom is a test suite that fails left and right when being checked out using Git for Windows (which defaults to core.autocrlf=true). Mostly, the problems stem from Git's (LF-only) output being compared to hard-coded files that are checked out with line endings according to core.autocrlf (which is of course incorrect). This includes the two test files in t/diff-lib/, README and COPYING. This patch can be validated even on Linux by using this cadence: git config core.autocrlf true rm .git/index && git stash make -j15 DEVELOPER=1 test Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2017, 04:32:51 UTC
8a7f8be Johannes Schindelin 09 May 2017, 12:54:24 UTC t3901: move supporting files into t/t3901/ The current convention is to either generate files on the fly in tests, or to use supporting files taken from a t/tNNNN/ directory (where NNNN matches the test's number, or the number of the test from which we borrow supporting files). The test t3901-i18n-patch.sh was obviously introduced before that convention was in full swing, hence its supporting files still lived in t/t3901-8859-1.txt and t/t3901-utf8.txt, respectively. Let's adjust to the current convention. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2017, 04:32:51 UTC
cedf4e2 Johannes Schindelin 09 May 2017, 12:54:20 UTC completion: mark bash script as LF-only Without this change, the completion script does not work, as Bash expects its scripts to have line feeds as end-of-line markers (this is particularly prominent in quoted multi-line strings, where carriage returns would slip into the strings as verbatim characters otherwise). This change is required to let t9902-completion pass when Git's source code is checked out with `core.autocrlf = true`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2017, 04:32:51 UTC
bee286f Johannes Schindelin 09 May 2017, 12:53:25 UTC git-new-workdir: mark script as LF-only Bash does not handle scripts with CR/LF line endings correctly, therefore they *have* to be forced to LF-only line endings. Funnily enough, this fixes t3000-ls-files-others and t1021-rerere-in-workdir when git.git was checked out with core.autocrlf=true, as these test still use git-new-workdir (once `git worktree` is no longer marked as experimental, both scripts probably want to be ported to using that command instead). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2017, 04:32:50 UTC
00ddc9d Johannes Schindelin 09 May 2017, 12:53:21 UTC Fix build with core.autocrlf=true On Windows, the default line endings are denoted by a Carriage Return byte followed by a Line Feed byte, while Linux and MacOSX use a single Line Feed byte to denote a line ending. To help with this situation, Git introduced several mechanisms over the last decade, most prominently the `core.autocrlf` setting. Sometimes, however, a single setting is incorrect, e.g. when certain files in the source code are to be consumed by software that can handle only LF line endings, while other files can use whatever is appropriate for the current platform. To allow for that, Git added the `eol` option to its .gitattributes handling, expecting every user of Git to mark their source code appropriately. Bash assumes that line-endings of scripts are denoted by a single Line Feed byte. Therefore, shell scripts in Git's source code are one example where that `eol=lf` option is *required*. When generating common-cmds.h, the Unix tools we use generally operate on the assumption that input and output deliminate their lines using LF-only line endings. Consequently, they would happily copy the CR byte verbatim into the strings in common-cmds.h, which in turn makes the C preprocessor barf (that interprets them as MacOS-style line endings). Therefore, we have to mark the input files as LF-only: command-list.txt and Documentation/git-*.txt. Quite a bit belatedly, this patch brings Git's own source code in line with those expectations by setting those attributes to allow for a correct build even when core.autocrlf=true. This patch can be validated even on Linux, by using this cadence: git config core.autocrlf true rm .git/index && git stash make -j15 DEVELOPER=1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2017, 04:32:50 UTC
cbaf82c Jonathan Tan 09 May 2017, 19:23:53 UTC receive-pack: verify push options in cert In commit f6a4e61 ("push: accept push options", 2016-07-14), send-pack was taught to include push options both within the signed cert (if the push is a signed push) and outside the signed cert; however, receive-pack ignores push options within the cert, only handling push options outside the cert. Teach receive-pack, in the case that push options are provided for a signed push, to verify that the push options both within the cert and outside the cert are consistent. This sets in stone the requirement that send-pack redundantly send its push options in 2 places, but I think that this is better than the alternatives. Sending push options only within the cert is backwards-incompatible with existing Git servers (which read push options only from outside the cert), and sending push options only outside the cert means that the push options are not signed for. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2017, 04:18:28 UTC
5840eb9 Junio C Hamano 08 May 2017, 01:38:59 UTC doc: replace more gmane links Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2017, 04:13:13 UTC
443a12f Junio C Hamano 08 May 2017, 04:21:06 UTC checkout: fix memory leak When "git checkout -m" does an in-core three-way merge to carry local modifications forward to check out a different branch, the code forgot to free the updated contents it has in-core. Noticed-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2017, 04:12:15 UTC
b06d364 Junio C Hamano 09 May 2017, 14:26:02 UTC Git 2.13 Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 May 2017, 14:26:02 UTC
951ea76 Junio C Hamano 09 May 2017, 14:25:26 UTC Merge tag 'l10n-2.13.0-rnd2.1' of git://github.com/git-l10n/git-po l10n for Git 2.13.0 round 2.1 * tag 'l10n-2.13.0-rnd2.1' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.13.0 l10n round 2 l10n: sv.po: Update Swedish translation (3195t0f0u) l10n: zh_CN: review for git v2.13.0 l10n round 1 l10n: Update Catalan translation l10n: bg.po: Updated Bulgarian translation (3195t) l10n: fr.po v2.13 rnd 2 l10n: de.po: translate 4 new messages l10n: de.po: update German translation l10n: de.po: lower case after semi-colon l10n: vi.po(3195t): Update translation for v2.13.0 round 2 l10n: git.pot: v2.13.0 round 2 (4 new, 7 removed) l10n: zh_CN: for git v2.13.0 l10n round 1 l10n: fr.po v2.13 round 1 l10n: pt_PT: update Portuguese translation l10n: bg.po: Updated Bulgarian translation (3201t) l10n: vi.po(3198t): Updated Vietnamese translation for v2.13.0-rc0 l10n: sv.po: Update Swedish translation (3199t0f0u) l10n: git.pot: v2.13.0 round 1 (96 new, 37 removed) 09 May 2017, 14:25:26 UTC
961f9c8 Jiang Xin 09 May 2017, 14:12:34 UTC Merge branch 'master' of git://github.com/nafmo/git-l10n-sv * 'master' of git://github.com/nafmo/git-l10n-sv: l10n: sv.po: Update Swedish translation (3195t0f0u) 09 May 2017, 14:12:34 UTC
60638e9 Jiang Xin 09 May 2017, 13:55:38 UTC l10n: zh_CN: for git v2.13.0 l10n round 2 Translate 4 messages (3195t0f0u) for git v2.13.0-rc2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 09 May 2017, 13:55:38 UTC
6402d7f Peter Krefting 09 May 2017, 07:05:09 UTC l10n: sv.po: Update Swedish translation (3195t0f0u) Signed-off-by: Peter Krefting <peter@softwolves.pp.se> 09 May 2017, 07:05:09 UTC
09fc7af Junio C Hamano 09 May 2017, 03:20:21 UTC Sync with v2.12.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 May 2017, 03:20:21 UTC
9b66978 Junio C Hamano 09 May 2017, 03:17:42 UTC Merge branch 'jh/verify-index-checksum-only-in-fsck' * jh/verify-index-checksum-only-in-fsck: t1450: avoid use of "sed" on the index, which is a binary file 09 May 2017, 03:17:42 UTC
b7b744f Jonathan Tan 08 May 2017, 21:33:50 UTC docs: correct receive.advertisePushOptions default In commit c714e45 ("receive-pack: implement advertising and receiving push options", 2016-07-14), receive-pack was taught to (among other things) advertise that it understood push options, depending on configuration. It was documented that it advertised such ability by default; however, it actually does not. (In that commit, notice that advertise_push_options defaults to 0, unlike advertise_atomic_push which defaults to 1.) Update the documentation to state that it does not advertise the ability by default. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 May 2017, 03:11:44 UTC
da5a1f8 Jeff King 09 May 2017, 02:59:46 UTC t5310: fix "; do" style Our usual shell style is to put the "do" of a loop on its own line, like: while $cond do something done instead of: while $cond; do something done We have a bit of both in our code base, but the former is what's in CodingGuidelines (and outnumbers the latter in t/ by about 6:1). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 May 2017, 03:09:03 UTC
9df4a60 Jeff King 09 May 2017, 02:54:13 UTC pack-objects: disable pack reuse for object-selection options If certain options like --honor-pack-keep, --local, or --incremental are used with pack-objects, then we need to feed each potential object to want_object_in_pack() to see if it should be filtered out. But when the bitmap reuse_packfile optimization is in effect, we do not call that function at all, and in fact skip adding the objects to the to_pack list entirely. This means we have a bug: for certain requests we will silently ignore those options and include objects in that pack that should not be there. The problem has been present since the inception of the pack-reuse code in 6b8fda2db (pack-objects: use bitmaps when packing objects, 2013-12-21), but it was unlikely to come up in practice. These options are generally used for on-disk packing, not transfer packs (which go to stdout), but we've never allowed pack reuse for non-stdout packs (until 645c432d6, we did not even use bitmaps, which the reuse optimization relies on; after that, we explicitly turned it off when not packing to stdout). We can fix this by just disabling the reuse_packfile optimization when the options are in use. In theory we could teach the pack-reuse code to satisfy these checks, but it's not worth the complexity. The purpose of the optimization is to keep the amount of per-object work we do to a minimum. But these options inherently require us to search for other copies of each object, drowning out any benefit of the pack-reuse optimization. But note that the optimizations from 56dfeb626 (pack-objects: compute local/ignore_pack_keep early, 2016-07-29) happen before pack-reuse, meaning that specifying "--honor-pack-keep" in a repository with no .keep files can still follow the fast path. There are tests in t5310 that check these options with bitmaps and --stdout, but they didn't catch the bug, and it's hard to adapt them to do so. One problem is that they don't use --delta-base-offset; without that option, we always disable the reuse optimization entirely. It would be fine to add it in (it actually makes the test more realistic), but that still isn't quite enough. The other problem is that the reuse code is very picky; it only kicks in when it can reuse most of a pack, starting from the first byte. So we'd have to start from a fully repacked and bitmapped state to trigger it. But the tests for these options use a much more subtle state; they want to be sure that the want_object_in_pack() code is allowing some objects but not others. Doing a full repack runs counter to that. So this patch adds new tests at the end of the script which create the fully-packed state and make sure that each option is not fooled by reusable pack. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 May 2017, 03:07:24 UTC
e294e89 Junio C Hamano 09 May 2017, 02:30:24 UTC apply.c: fix whitespace-only mismerge 4af9a7d3 ("Merge branch 'bc/object-id'", 2016-09-19) involved merging a lot of changes made to builtin/apply.c on the side branch manually to apply.c as an intervening commit 13b5af22 ("apply: move libified code from builtin/apply.c to apply.{c,h}", 2016-04-22) moved a lot of the lines changed on the side branch to a different file apply.c at the top-level, requiring manual patching of it. Apparently, the maintainer screwed up and made the code indent in a funny way while doing so. Reported-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 May 2017, 02:33:31 UTC
back to top