summaryrefslogtreecommitdiffstats
path: root/userdiff.h (unfollow)
Commit message (Collapse)AuthorFilesLines
2017-12-08test-lib: silence "-x" cleanup under bashJeff King1-10/+24
When the test suite's "-x" option is used with bash, we end up seeing cleanup cruft in the output: $ bash t0001-init.sh -x [...] ++ diff -u expected actual + test_eval_ret_=0 + want_trace + test t = t + test t = t + set +x ok 42 - re-init from a linked worktree This ranges from mildly annoying (for a successful test) to downright confusing (when we say "last command exited with error", but it's really 5 commands back). We normally are able to suppress this cleanup. As the in-code comment explains, we can't convince the shell not to print it, but we can redirect its stderr elsewhere. But since d88785e424 (test-lib: set BASH_XTRACEFD automatically, 2016-05-11), that doesn't hold for bash. It sends the "set -x" output directly to descriptor 4, not to stderr. We can fix this by also redirecting descriptor 4, and paying close attention to which commands redirected and which are not (see the updated comment). Two alternatives I considered and rejected: - unsetting and setting BASH_XTRACEFD; doing so closes the descriptor, which we must avoid - we could keep everything in a single block as before, redirect 4>/dev/null there, but retain 5>&4 as a copy. And then selectively restore 4>&5 for commands which should be allowed to trace. This would work, but the descriptor swapping seems unnecessarily confusing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06Prepare for 2.15.2Junio C Hamano2-1/+48
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-28Git 2.15.1v2.15.1Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27A bit more fixes for 2.15.1Junio C Hamano1-0/+5
We've been waiting long enough, a few more would not hurt ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-26RelNotes: minor typo fixes in 2.15.1 draftTodd Zullinger1-3/+3
Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-21Almost ready for 2.15.1Junio C Hamano1-0/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-21pull: pass -4/-6 option to 'git fetch'Shuyu Wei1-0/+12
The -4/-6 option should be passed through to 'git fetch' to be consistent with the man page. Signed-off-by: Wei Shuyu <wsy@dogben.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-18config: flip return value of write_section()René Scharfe1-1/+1
d9bd4cbb9cc (config: flip return value of store_write_*()) made write_section() follow the convention of write(2) to return -1 on error and the number of written bytes on success. 3b48045c6c7 (Merge branch 'sd/branch-copy') changed it back to returning 0 on error and 1 on success, but left its callers still checking for negative values. Let write_section() follow the convention of write(2) again to meet the expectations of its callers. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-18rebase: use mboxrd format to avoid split errorsEric Wong2-0/+24
The mboxrd format allows the use of embedded "From " lines in commit messages without being misinterpreted by mailsplit Reported-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-17apply: update line lengths for --inaccurate-eofRené Scharfe2-0/+16
Some diff implementations don't report missing newlines at the end of files. Applying such a patch can cause a newline character to be added inadvertently. The option --inaccurate-eof of git apply can be used to remove trailing newlines if needed. apply_one_fragment() cuts it off from the buffers for preimage and postimage. Before it does, it builds an array with the lengths of each line for both. Make sure to update the length of the last line in these line info structures as well to keep them consistent with their respective buffer. Without this fix the added test fails; git apply dies and reports: fatal: BUG: caller miscounted postlen: asked 1, orig = 1, used = 2 That sanity check is only called if whitespace changes are ignored. Reported-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-17completion: add '--copy' option to 'git branch'Todd Zullinger1-1/+1
In 52d59cc645 (branch: add a --copy (-c) option to go with --move (-m), 2017-06-18), `git branch` learned a `--copy` option. Include it when providing command completions. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-16sequencer: reschedule pick if index can't be lockedPhillip Wood1-1/+2
If the index cannot be locked in do_recursive_merge(), issue an error message and go on to the error recovery codepath, instead of dying. When the commit cannot be picked, it needs to be rescheduled when performing an interactive rebase, but just dying there won't allow that to happen, and when the user runs 'git rebase --continue' rather than 'git rebase --abort', the commit gets silently dropped. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
2017-11-16config: avoid "write_in_full(fd, buf, len) != len" patternPhillip Wood1-2/+2
As explained in commit 06f46f237 (avoid "write_in_full(fd, buf, len) != len" pattern, 2017–09–13) the return value of write_in_full() is either -1 or the requested number of bytes. As such comparing the return value to an unsigned value such as strbuf.len will fail to catch errors. Change the code to use the preferred '< 0' check. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-15merge-recursive: handle addition of submodule on our side of historyElijah Newren2-3/+4
The code for a newly added path assumed that the path was a normal file, and thus checked for there being a directory still being in the way of the file. Note that since unpack_trees() does path-in-the-way checks already, the only way for there to be a directory in the way at this point in the code, is if there is some kind of D/F conflict in the merge. For a submodule addition on HEAD's side of history, the submodule would have already been present. This means that we do expect there to be a directory present but should not consider it to be "in the way"; instead, it's the expected submodule. So, when there's a submodule addition from HEAD's side, don't bother checking the working copy for a directory in the way. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-15Start preparation for 2.15.1Junio C Hamano3-2/+70
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-15notes: send "Automatic notes merge failed" messages to stderrTodd Zullinger3-9/+9
All other error messages from notes use stderr. Do the same when alerting users of an unresolved notes merge. Fix the output redirection in t3310 and t3320 as well. Previously, the tests directed output to a file, but stderr was either not captured or not sent to the file due to the order of the redirection operators. Signed-off-by: Todd Zullinger <tmz@pobox.com> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-14rebase: fix stderr redirect in apply_autostash()Todd Zullinger1-1/+1
The intention is to ignore all output from the 'git stash apply' call. Adjust the order of the redirection to ensure that both stdout and stderr are redirected to /dev/null. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-14t/lib-gpg: fix gpgconf stderr redirect to /dev/nullTodd Zullinger1-1/+1
In 29ff1f8f74 (t: lib-gpg: flush gpg agent on startup, 2017-07-20), a call to gpgconf was added to kill the gpg-agent. The intention was to ignore all output from the call, but the order of the redirection needs to be switched to ensure that both stdout and stderr are redirected to /dev/null. Without this, gpgconf from gnupg-2.0 releases would output 'gpgconf: invalid option "--kill"' each time it was called. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-13link_alt_odb_entries: make empty input a noopJeff King1-1/+3
If an empty string is passed to link_alt_odb_entries(), our loop finds no entries and we link nothing. But we still do some preparatory work to normalize the object directory path, even though we'll never look at the result. This triggers in basically every git process, since we feed the usually-empty ALTERNATE_DB_ENVIRONMENT to the function. Let's detect early that there's nothing to do and return. While we're at it, let's treat NULL the same as an empty string as a favor to our callers. That saves prepare_alt_odb() from having to cover this case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-13Documentation: convert SubmittingPatches to AsciiDocbrian m. carlson3-161/+191
The SubmittingPatches document is often cited by outside parties as an example of good practices to follow, including logical, independent commits; patch sign-offs; and sending patches to a mailing list. Currently, people who want to cite a particular section tend to either refer to it by name and let the interested party search through the document to find it, or link to a given line number on GitHub and hope the file doesn't change. Instead, convert the document to AsciiDoc. Build it as part of the technical documentation, since it is likely of interest to the same group of people. Provide stable links to the sections which outside parties are likely to want to link to. Make some minor structural changes to organize it so that it can be formatted sanely. Since the makefile needs a .txt extension in order to build with the rest of the documentation, simply copy the file. Ignore the temporary file so it doesn't get checked in accidentally, and remove it as part of the clean process. Do this instead of renaming the file so that people who have already linked to the documentation (who we're trying to help) don't find their links broken. Avoid symlinking since Windows will not like that. This allows us to render the document as part of the website for the benefit of others who wish to link to it as well as providing a more nicely formatted display for our community and potential contributors. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-13grep: fix NO_LIBPCRE1_JIT to fully disable JITCharles Bailey2-3/+4
If you have a pcre1 library which is compiled with JIT enabled then PCRE_STUDY_JIT_COMPILE will be defined whether or not the NO_LIBPCRE1_JIT configuration is set. This means that we enable JIT functionality when calling pcre_study even if NO_LIBPCRE1_JIT has been explicitly set and we just use plain pcre_exec later. Fix this by using own macro (GIT_PCRE_STUDY_JIT_COMPILE) which we set to PCRE_STUDY_JIT_COMPILE only if NO_LIBPCRE1_JIT is not set and define to 0 otherwise, as before. Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-13t4201: make use of abbreviation in the test more robustCharles Bailey2-5/+7
The test for '--abbrev' in t4201-shortlog.sh assumes that the commits generated in the test can always be uniquely abbreviated to 5 hex digits but this is not always the case. If you were unlucky and happened to run the test at (say) Thu Jun 22 03:04:49 2017 +0000, you would find that the first commit generated would collide with a tree object created later in the same test. This can be simulated in the version of t4201-shortlog.sh prior to this commit by setting GIT_COMMITTER_DATE and GIT_AUTHOR_DATE to 1498100689 after sourcing test-lib.sh. Change the test to test --abbrev=35 instead of --abbrev=5 to almost completely avoid the possibility of a partial collision and add a call to test_tick in the setup to make the test repeatable (the latter alone is sufficient to make it robust enough). Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-12t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failureStefan Beller1-0/+36
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-12apply: avoid out-of-bounds access in fuzzy_matchlines()René Scharfe1-39/+20
fuzzy_matchlines() uses a pointers to the first and last characters of two lines to keep track while matching them. This makes it impossible to deal with empty strings. It accesses characters before the start of empty lines. It can also access characters after the end when checking for trailing whitespace in the main loop. Avoid that by using pointers to the first character and the one *after* the last one. This is well-defined as long as the latter is not dereferenced. Basically rewrite the function based on that premise; it becomes much simpler as a result. There is no need to check for leading whitespace outside of the main loop anymore. Reported-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-10doc/SubmittingPatches: correct subject guidanceAdam Dinwoodie1-8/+13
The examples and common practice for adding markers such as "RFC" or "v2" to the subject of patch emails is to have them within the same brackets as the "PATCH" text, not after the closing bracket. Further, the practice of `git format-patch` and the like, as well as what appears to be the more common pratice on the mailing list, is to use "[RFC PATCH]", not "[PATCH/RFC]". Update the SubmittingPatches article to match and to reference the `format-patch` helper arguments, and also make some minor text clarifications in the area. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-09Replace Free Software Foundation address in license noticesTodd Zullinger1-2/+1
The mailing address for the FSF has changed over the years. Rather than updating the address across all files, refer readers to gnu.org, as the GNU GPL documentation now suggests for license notices. The mailing address is retained in the full license files (COPYING and LGPL-2.1). Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-09Replace Free Software Foundation address in license noticesTodd Zullinger43-101/+68
The mailing address for the FSF has changed over the years. Rather than updating the address across all files, refer readers to gnu.org, as the GNU GPL documentation now suggests for license notices. The mailing address is retained in the full license files (COPYING and LGPL-2.1). The old address is still present in t/diff-lib/COPYING. This is intentional, as the file is used in tests and the contents are not expected to change. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-09rebase -i: fix comment typoAdam Dinwoodie1-1/+1
Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-09merge-base --fork-point doc: clarify the example and failure modesJunio C Hamano1-8/+56
The illustrated history used to explain the `--fork-point` mode named three keypoint commits B3, B2 and B1 from the oldest to the newest, which was hard to read. Relabel them to B0, B1, B2. Also illustrate the history after the rebase using the `--fork-point` facility was made. The text already mentions use of reflog, but the description is not clear what benefit we are trying to gain by using reflog. Clarify that it is to find the commits that were known to be at the tip of the remote-tracking branch. This in turn necessitates users to know the ramifications of the underlying assumptions, namely, expiry of reflog entries will make it impossible to determine which commits were at the tip of the remote-tracking branches and we fail when in doubt (instead of giving a random and incorrect result without even warning). Another limitation is that it won't be useful if you did not fork from the tip of a remote-tracking branch but from in the middle. Describe them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-08reduce_heads: fix memory leaksMartin Ågren7-6/+35
We currently have seven callers of `reduce_heads(foo)`. Six of them do not use the original list `foo` again, and actually, all six of those end up leaking it. Introduce and use `reduce_heads_replace(&foo)` as a leak-free version of `foo = reduce_heads(foo)` to fix several of these. Fix the remaining leaks using `free_commit_list()`. While we're here, document `reduce_heads()` and mark it as `extern`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-08builtin/merge-base: free commit listsMartin Ågren1-18/+18
In several functions, we iterate through a commit list by assigning `result = result->next`. As a consequence, we lose the original pointer and eventually leak the list. Rewrite the loops so that we keep the original pointers, then call `free_commit_list()`. Various alternatives were considered: 1) Use `UNLEAK(result)` before the loop. Simple change, but not very pretty. These would definitely be new lows among our usages of UNLEAK. 2) Use `pop_commit()` when looping. Slightly less simple change, but it feels slightly preferable to first display the list, then free it. 3) As in this patch, but with `UNLEAK()` instead of freeing. We'd still go through all the trouble of refactoring the loop, and because it's not super-obvious that we're about to exit, let's just free the lists -- it probably doesn't affect the runtime much. In `handle_independent()` we can drop `result` while we're here and reuse the `revs`-variable instead. That matches several other users of `reduce_heads()`. The memory-leak that this hides will be addressed in the next commit. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-07wt-status: actually ignore submodules when requestedBrandon Williams2-1/+20
Since ff6f1f564 (submodule-config: lazy-load a repository's .gitmodules file, 2017-08-03) rebase interactive fails if there are any submodules with unstaged changes which have been configured with a value for 'submodule.<name>.ignore' in the repository's config. This is due to how configured values of 'submodule.<name>.ignore' are handled in addition to a change in how the submodule config is loaded. When the diff machinery hits a submodule (gitlink as well as a corresponding entry in the submodule subsystem) it will read the value of 'submodule.<name>.ignore' stored in the repository's config and if the config is present it will clear the 'IGNORE_SUBMODULES' (which is the flag explicitly requested by rebase interactive), 'IGNORE_UNTRACKED_IN_SUBMODULES', and 'IGNORE_DIRTY_SUBMODULES' diff flags and then set one of them based on the configured value. Historically this wasn't a problem because the submodule subsystem wasn't initialized because the .gitmodules file wasn't explicitly loaded by the rebase interactive command. So when the diff machinery hit a submodule it would skip over reading any configured values of 'submodule.<name>.ignore'. In order to preserve the behavior of submodules being ignored by rebase interactive, also set the 'OVERRIDE_SUBMODULE_CONFIG' diff flag when submodules are requested to be ignored when checking for unstaged changes. Reported-by: Orgad Shaneh <orgads@gmail.com> Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06wrapper.c: consistently quote filenames in error messagesSimon Ruderich3-6/+6
All other error messages in the file use quotes around the file name. This change removes two translations as "could not write to '%s'" and "could not close '%s'" are already translated and these two are the only occurrences without quotes. Signed-off-by: Simon Ruderich <simon@ruderich.org> [jc: adjusted tests I noticed were broken by the change] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06fix typos in 2.15.0 release notesJean Carlo Machado1-3/+3
Signed-off-by: Jean Carlo Machado <contato@jeancarlomachado.com.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06bisect: fix memory leak when returning best elementMartin Ågren1-1/+5
When `find_bisection()` returns a single list entry, it leaks the other entries. Move the to-be-returned item to the front and free the remainder. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06bisect: fix off-by-one error in `best_bisection_sorted()`Martin Ågren1-3/+4
After we have sorted the `cnt`-many commits that we have selected, we place them into the commit list. We then set `p->next` to NULL, but as we do so, `p` is already pointing one beyond item number `cnt`. Indeed, we check whether `p` is NULL before dereferencing it. This only matters if there are TREESAME-commits. Since they should be skipped, they are not included in `cnt` and we will hit the situation where we set `p->next` to NULL. As a result, the list will be one longer than it should be. The last commit in the list will be one which occurs earlier, or which shouldn't be included. Do not update `p` the very last round in the loop. This ensures that after the loop, `p->next` points to the remainder of the list, and we can set it to NULL. While we're here, free that remainder to fix a memory leak. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06bisect: fix memory leak in `find_bisection()`Martin Ågren1-1/+3
`find_bisection()` rebuilds the commit list it is given by reversing it and skipping uninteresting commits. The uninteresting list entries are leaked. Free them to fix the leak. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06bisect: change calling-convention of `find_bisection()`Martin Ågren3-14/+17
This function takes a commit list and returns a commit list. The returned list is built by modifying the original list. Thus the caller should not use the original list again (and after the next commit fixes a memory leak, it must not). Change the function signature so that it takes a **list and has void return type. That should make it harder to misuse this function. While we're here, document this function. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06config: document blame configurationStefan Beller1-0/+17
The options are currently only referenced by the git-blame man page, also explain them in git-config, which is the canonical page to contain all config options. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-04credential-libsecret: unlock locked secretsDennis Kaarsemaker1-1/+1
Credentials exposed by the secret service DBUS interface may be locked. Setting the SECRET_SEARCH_UNLOCK flag will make the secret service unlock these secrets, possibly prompting the user for credentials to do so. Without this flag, the secret is simply not loaded. Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-03setup: avoid double slashes when looking for HEADJeff King1-1/+3
Andrew Baumann reported that when called outside of any Git worktree, `git rev-parse --is-inside-work-tree` eventually tries to access `//HEAD`, i.e. any `HEAD` file in the root directory, but with a double slash. This double slash is not only unintentional, but is allowed by the POSIX standard to have a special meaning. And most notably on Windows, it does, where it refers to a UNC path of the form `//server/share/`. As a consequence, afore-mentioned `rev-parse` call not only looks for the wrong thing, but it also causes serious delays, as Windows will try to access a server called `HEAD`. Let's simply avoid the unintended double slash. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-03mailmap: use Kaartic Sivaraam's new addressKaartic Sivaraam1-0/+1
Map the old address to the new, hopefully more permanent one. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-03imap-send: handle missing response codes gracefullyRené Scharfe1-1/+1
Response codes are optional. Exit parse_response_code() early if it's passed a NULL string, indicating that we reached the end of the reply. This avoids dereferencing said NULL pointer. Noticed-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-03imap-send: handle NULL return of next_arg()René Scharfe1-1/+12
next_arg() returns NULL if it runs out of arguments. Most call sites already handle that gracefully. Check in the remaining cases as well. Replace the NULL pointer with an empty string at the bottom of get_cmd_result() -- it's nicely reported as an unexpected response a few lines down. Error out explicitly at the remaining sites. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02diff: --indent-heuristic is no longer experimentalCarlos Martín Nieto4-9/+6
This heuristic has been the default since 2.14 so we should not confuse our users by saying that it's experimental and off by default. Signed-off-by: Carlos Martín Nieto <cmn@dwim.me> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02sequencer.c: check return value of close() in rewrite_file()Simon Ruderich1-1/+2
Not checking close(2) can hide errors as not all errors are reported during the write(2). Signed-off-by: Simon Ruderich <simon@ruderich.org> Reviewed-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02mingw: document the standard handle redirectionJohannes Schindelin1-0/+18
This feature has been in Git for Windows since v2.11.0(2), as an experimental option. Now it is considered mature, and it is high time to document it properly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02mingw: optionally redirect stderr/stdout via the same handleJohannes Schindelin2-1/+22
The "2>&1" notation in Powershell and in Unix shells implies that stderr is redirected to the same handle into which stdout is already written. Let's use this special value to allow the same trick with GIT_REDIRECT_STDERR and GIT_REDIRECT_STDOUT: if the former's value is `2>&1`, then stderr will simply be written to the same handle as stdout. The functionality was suggested by Jeff Hostetler. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02mingw: add experimental feature to redirect standard handlesJohannes Schindelin2-0/+49
Particularly when calling Git from applications, such as Visual Studio's Team Explorer, it is important that stdin/stdout/stderr are closed properly. However, when spawning processes on Windows, those handles must be marked as inheritable if we want to use them, but that flag is a global flag and may very well be used by other spawned processes which then do not know to close those handles. Let's introduce a set of environment variables (GIT_REDIRECT_STDIN and friends) that specify paths to files, or even better, named pipes (which are similar to Unix sockets) and that are used by the spawned Git process. This helps work around above-mentioned issue: those named pipes will be opened in a non-inheritable way upon startup, and no handles are passed around (and therefore no inherited handles need to be closed by any spawned child). This feature shipped with Git for Windows (marked as experimental) since v2.11.0(2), so it has seen some serious testing in the meantime. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-02travis-ci: don't build Git for the static analysis jobSZEDER Gábor1-1/+1
The static analysis job on Travis CI builds Git ever since it was introduced in d8245bb3f (travis-ci: add static analysis build job to run coccicheck, 2017-04-11). However, Coccinelle, the only static analysis tool in use, only needs Git's source code to work and it doesn't care about built Git binaries at all. Spare some of Travis CI's resources and don't build Git for the static analysis job unnecessarily. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>