summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-06-05Merge branch 'sg/core-filemode-doc-typofix' into maintLibravatar Junio C Hamano1-1/+1
* sg/core-filemode-doc-typofix: docs/config.txt: fix indefinite article in core.fileMode description
2017-06-05Merge branch 'tb/dedup-crlf-tests' into maintLibravatar Junio C Hamano2-187/+0
* tb/dedup-crlf-tests: t0027: tests are not expensive; remove t0025
2017-06-05Merge branch 'jn/credential-doc-on-clear' into maintLibravatar Junio C Hamano1-10/+10
Doc update. * jn/credential-doc-on-clear: credential doc: make multiple-helper behavior more prominent
2017-06-05Merge branch 'jk/url-insteadof-config' into maintLibravatar Junio C Hamano2-0/+17
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
2017-06-05Merge branch 'jk/unbreak-am-h' into maintLibravatar Junio C Hamano1-0/+3
"git am -h" triggered a BUG(). * jk/unbreak-am-h: am: handle "-h" argument earlier
2017-06-05Merge branch 'ab/sha1dc-maint' into maintLibravatar Junio C Hamano7-88/+172
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
2017-06-05Merge branch 'js/bs-is-a-dir-sep-on-windows' into maintLibravatar Junio C Hamano2-2/+11
"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
2017-06-05Merge branch 'jk/alternate-ref-optim' into maintLibravatar Junio C Hamano1-1/+4
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
2017-06-05Merge branch 'bm/interpret-trailers-cut-line-is-eom' into maintLibravatar Junio C Hamano5-13/+32
"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
2017-06-05Merge branch 'kn/ref-filter-branch-list' into maintLibravatar Junio C Hamano1-7/+9
"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
2017-06-05Merge branch 'rs/checkout-am-fix-unborn' into maintLibravatar Junio C Hamano2-2/+3
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
2017-06-05Merge branch 'jn/clone-add-empty-config-from-command-line' into maintLibravatar Junio C Hamano2-1/+11
"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
2017-06-05Merge branch 'ab/c-translators-comment-style' into maintLibravatar Junio C Hamano9-26/+46
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
2017-06-05Merge branch 'ls/travis-doc-asciidoctor' into maintLibravatar Junio C Hamano2-4/+16
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
2017-06-04Prepare for 2.13.1; more topics to followLibravatar Junio C Hamano2-1/+70
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-04Merge branch 'tg/stash-push-fixup' into maintLibravatar Junio C Hamano1-1/+4
The shell completion script (in contrib/) learned "git stash" has a new "push" subcommand. * tg/stash-push-fixup: completion: add git stash push
2017-06-04Merge branch 'km/log-showsignature-doc' into maintLibravatar Junio C Hamano1-0/+4
Doc update. * km/log-showsignature-doc: config.txt: add an entry for log.showSignature
2017-06-04Merge branch 'jt/use-trailer-api-in-commands' into maintLibravatar Junio C Hamano2-7/+48
"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
2017-06-04Merge branch 'jt/push-options-doc' into maintLibravatar Junio C Hamano4-11/+114
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
2017-06-04Merge branch 'js/plug-leaks' into maintLibravatar Junio C Hamano23-64/+149
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 ...
2017-06-04Merge branch 'js/eol-on-ourselves' into maintLibravatar Junio C Hamano11-26/+55
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
2017-06-04Merge branch 'jk/update-links-in-docs' into maintLibravatar Junio C Hamano3-3/+3
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
2017-06-04Merge branch 'jk/ignore-broken-tags-when-ignoring-missing-links' into maintLibravatar Junio C Hamano2-2/+27
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
2017-06-04Merge branch 'jk/doc-config-include' into maintLibravatar Junio C Hamano1-10/+21
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
2017-06-04Merge branch 'jk/disable-pack-reuse-when-broken' into maintLibravatar Junio C Hamano2-4/+50
"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
2017-06-04Merge branch 'jk/am-leakfix' into maintLibravatar Junio C Hamano1-20/+14
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()
2017-06-04Merge branch 'jc/read-tree-empty-with-m' into maintLibravatar Junio C Hamano1-1/+1
"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
2017-06-04Merge branch 'jc/apply-fix-mismerge' into maintLibravatar Junio C Hamano1-169/+169
Mismerge fix. * jc/apply-fix-mismerge: apply.c: fix whitespace-only mismerge
2017-06-04Merge branch 'ja/do-not-ask-needless-questions' into maintLibravatar Junio C Hamano6-11/+12
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
2017-06-04Merge branch 'bw/submodule-with-bs-path' into maintLibravatar Junio C Hamano1-1/+1
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'
2017-06-04Merge branch 'ah/log-decorate-default-to-auto' into maintLibravatar Junio C Hamano2-2/+14
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
2017-06-04Merge branch 'ab/fix-poison-tests' into maintLibravatar Junio C Hamano16-37/+48
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
2017-06-04Merge branch 'ab/doc-replace-gmane-links' into maintLibravatar Junio C Hamano5-6/+6
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
2017-06-04Merge branch 'ab/aix-needs-compat-regex' into maintLibravatar Junio C Hamano1-0/+1
Build fix. * ab/aix-needs-compat-regex: config.mak.uname: set NO_REGEX=NeedsStartEnd on AIX
2017-06-04Merge branch 'pw/rebase-i-regression-fix' into maintLibravatar Junio C Hamano1-1/+4
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
2017-06-01docs/config: mention protocol implications of url.insteadOfLibravatar Jeff King2-0/+17
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>
2017-05-31C style: use standard style for "TRANSLATORS" commentsLibravatar Ævar Arnfjörð Bjarmason9-26/+46
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>
2017-05-30am: handle "-h" argument earlierLibravatar Jeff King1-0/+3
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>
2017-05-26docs/config.txt: fix indefinite article in core.fileMode descriptionLibravatar SZEDER Gábor1-1/+1
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-26Windows: do not treat a path with backslashes as a remote's nick nameLibravatar Johannes Sixt1-1/+6
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>
2017-05-23mingw.h: permit arguments with side effects for is_dir_sepLibravatar Johannes Sixt1-1/+5
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>
2017-05-22sha1dc: update from upstreamLibravatar Ævar Arnfjörð Bjarmason7-88/+172
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>
2017-05-20revision.c: ignore broken tags with ignore_missing_linksLibravatar Jeff King2-2/+27
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>
2017-05-20config.txt: add an entry for log.showSignatureLibravatar Kyle Meyer1-0/+4
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>
2017-05-20rebase -i: add missing newline to end of messageLibravatar Phillip Wood1-1/+1
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>
2017-05-20rebase -i: silence stash applyLibravatar Phillip Wood1-0/+2
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>
2017-05-20rebase -i: fix reflog messageLibravatar Phillip Wood1-0/+1
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>
2017-05-20ref-filter: resolve HEAD when parsing %(HEAD) atomLibravatar Jeff King1-7/+9
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>
2017-05-18interpret-trailers: honor the cut lineLibravatar Brian Malehorn5-13/+32
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>
2017-05-18t5400: avoid concurrent writes into a trace fileLibravatar Jeff King1-1/+4
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>