summaryrefslogtreecommitdiff
path: root/wt-status.c
AgeCommit message (Collapse)AuthorFilesLines
2015-11-05Merge branch 'rs/wt-status-detached-branch-fix' into maintLibravatar Junio C Hamano1-35/+29
"git status --branch --short" accessed beyond the constant string "HEAD", which has been corrected. * rs/wt-status-detached-branch-fix: wt-status: use skip_prefix() to get rid of magic string length constants wt-status: don't skip a magical number of characters blindly wt-status: avoid building bogus branch name with detached HEAD wt-status: exit early using goto in wt_shortstatus_print_tracking() t7060: add test for status --branch on a detached HEAD
2015-11-01wt-status: use skip_prefix() to get rid of magic string length constantsLibravatar René Scharfe1-21/+15
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01wt-status: don't skip a magical number of characters blindlyLibravatar René Scharfe1-1/+1
Use the variable branch_name, which already has "refs/heads/" removed, instead of blindly advancing in the ->branch string by 11 bytes. This is safer and less magical. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01wt-status: avoid building bogus branch name with detached HEADLibravatar René Scharfe1-6/+9
If we're on a detached HEAD then wt_shortstatus_print_tracking() takes the string "HEAD (no branch)", translates it, skips the first eleven characters and passes the result to branch_get(), which returns a bogus result and accesses memory out of bounds in order to produce it. Somehow stat_tracking_info(), which is passed that result, does the right thing anyway, i.e. it finds that there is no base. Avoid the bogus results and memory accesses by checking for HEAD first and exiting early in that case. This fixes t7060 with --valgrind. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01wt-status: exit early using goto in wt_shortstatus_print_tracking()Libravatar René Scharfe1-8/+5
Deduplicate printing the line terminator by jumping to the end of the function. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16Merge branch 'mm/detach-at-HEAD-reflog' into maintLibravatar Junio C Hamano1-0/+6
After "git checkout --detach", "git status" reported a fairly useless "HEAD detached at HEAD", instead of saying at which exact commit. * mm/detach-at-HEAD-reflog: status: don't say 'HEAD detached at HEAD' t3203: test 'detached at' after checkout --detach
2015-10-02status: don't say 'HEAD detached at HEAD'Libravatar Matthieu Moy1-0/+6
After using "git checkout --detach", the reflog is left with an entry like checkout: moving from ... to HEAD This message is parsed to generate the 'HEAD detached at' message in 'git branch' and 'git status', which leads to the not-so-useful message 'HEAD detached at HEAD'. Instead, when parsing such reflog entry, resolve HEAD to the corresponding commit in the reflog, so that the message becomes 'HEAD detached at $sha1'. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-03Merge branch 'sg/wt-status-header-inclusion' into maintLibravatar Junio C Hamano1-1/+0
* sg/wt-status-header-inclusion: wt-status: move #include "pathspec.h" to the header
2015-08-26Merge branch 'sg/wt-status-header-inclusion'Libravatar Junio C Hamano1-1/+0
* sg/wt-status-header-inclusion: wt-status: move #include "pathspec.h" to the header
2015-08-21wt-status: move #include "pathspec.h" to the headerLibravatar SZEDER Gábor1-1/+0
The declaration of 'struct wt_status' requires the declararion of 'struct pathspec'. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10memoize common git-path "constant" filesLibravatar Jeff King1-4/+4
One of the most common uses of git_path() is to pass a constant, like git_path("MERGE_MSG"). This has two drawbacks: 1. The return value is a static buffer, and the lifetime is dependent on other calls to git_path, etc. 2. There's no compile-time checking of the pathname. This is OK for a one-off (after all, we have to spell it correctly at least once), but many of these constant strings appear throughout the code. This patch introduces a series of functions to "memoize" these strings, which are essentially globals for the lifetime of the program. We compute the value once, take ownership of the buffer, and return the cached value for subsequent calls. cache.h provides a helper macro for defining these functions as one-liners, and defines a few common ones for global use. Using a macro is a little bit gross, but it does nicely document the purpose of the functions. If we need to touch them all later (e.g., because we learned how to change the git_dir variable at runtime, and need to invalidate all of the stored values), it will be much easier to have the complete list. Note that the shared-global functions have separate, manual declarations. We could do something clever with the macros (e.g., expand it to a declaration in some places, and a declaration _and_ a definition in path.c). But there aren't that many, and it's probably better to stay away from too-magical macros. Likewise, if we abandon the C preprocessor in favor of generating these with a script, we could get much fancier. E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz". But the small amount of saved typing is probably not worth the resulting confusion to readers who want to grep for the function's definition. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'gp/status-rebase-i-info'Libravatar Junio C Hamano1-17/+134
Teach "git status" to show a more detailed information regarding the "rebase -i" session in progress. * gp/status-rebase-i-info: status: add new tests for status during rebase -i status: give more information during rebase -i status: differentiate interactive from non-interactive rebases status: factor two rebase-related messages together
2015-08-03Merge branch 'sg/commit-cleanup-scissors' into maintLibravatar Junio C Hamano1-4/+5
"git commit --cleanup=scissors" was not careful enough to protect against getting fooled by a line that looked like scissors. * sg/commit-cleanup-scissors: commit: cope with scissors lines in commit message
2015-07-06status: give more information during rebase -iLibravatar Guillaume Pagès1-0/+114
git status gives more information during rebase -i, about the list of command that are done during the rebase. It displays the two last commands executed and the two next lines to be executed. It also gives hints to find the whole files in .git directory. Signed-off-by: Guillaume Pagès <guillaume.pages@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30status: differentiate interactive from non-interactive rebasesLibravatar Guillaume Pagès1-1/+4
Signed-off-by: Guillaume Pagès <guillaume.pages@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30status: factor two rebase-related messages togetherLibravatar Guillaume Pagès1-16/+16
Signed-off-by: Guillaume Pagès <guillaume.pages@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-24Merge branch 'sg/commit-cleanup-scissors'Libravatar Junio C Hamano1-4/+5
"git commit --cleanup=scissors" was not careful enough to protect against getting fooled by a line that looked like scissors. * sg/commit-cleanup-scissors: commit: cope with scissors lines in commit message
2015-06-09commit: cope with scissors lines in commit messageLibravatar SZEDER Gábor1-4/+5
The diff and submodule shortlog appended to the commit message template by 'git commit --verbose' are not stripped when the commit message contains an indented scissors line. When cleaning up a commit message with 'git commit --verbose' or '--cleanup=scissors' the code is careful and triggers only on a pure scissors line, i.e. a line containing nothing but a comment character, a space, and the scissors cut. This is good, because people can embed scissors lines in the commit message while using 'git commit --verbose', and the text they write after their indented scissors line doesn't get deleted. While doing so, however, the cleanup function only looks at the first line matching the scissors pattern and if it doesn't start at the beginning of the line, then the function just returns without performing any cleanup. This is wrong, because a "real" scissors line added by 'git commit --verbose' might follow, and in that case the diff and submodule shortlog get included in the commit message. Fix this by changing the scissors pattern to match only at the beginning of the line, yet be careful to catch scissors on the first line as well. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-05Merge branch 'jk/at-push-sha1'Libravatar Junio C Hamano1-12/+6
Introduce <branch>@{push} short-hand to denote the remote-tracking branch that tracks the branch at the remote the <branch> would be pushed to. * jk/at-push-sha1: for-each-ref: accept "%(push)" format for-each-ref: use skip_prefix instead of starts_with sha1_name: implement @{push} shorthand sha1_name: refactor interpret_upstream_mark sha1_name: refactor upstream_mark remote.c: add branch_get_push remote.c: return upstream name from stat_tracking_info remote.c: untangle error logic in branch_get_upstream remote.c: report specific errors from branch_get_upstream remote.c: introduce branch_get_upstream helper remote.c: hoist read_config into remote_get_1 remote.c: provide per-branch pushremote name remote.c: hoist branch.*.remote lookup out of remote_get_1 remote.c: drop "remote" pointer from "struct branch" remote.c: refactor setup of branch->merge list remote.c: drop default_remote_name variable
2015-05-26Merge branch 'nd/untracked-cache'Libravatar Junio C Hamano1-0/+2
Teach the index to optionally remember already seen untracked files to speed up "git status" in a working tree with tons of cruft. * nd/untracked-cache: (24 commits) git-status.txt: advertisement for untracked cache untracked cache: guard and disable on system changes mingw32: add uname() t7063: tests for untracked cache update-index: test the system before enabling untracked cache update-index: manually enable or disable untracked cache status: enable untracked cache untracked-cache: temporarily disable with $GIT_DISABLE_UNTRACKED_CACHE untracked cache: mark index dirty if untracked cache is updated untracked cache: print stats with $GIT_TRACE_UNTRACKED_STATS untracked cache: avoid racy timestamps read-cache.c: split racy stat test to a separate function untracked cache: invalidate at index addition or removal untracked cache: load from UNTR index extension untracked cache: save to an index extension ewah: add convenient wrapper ewah_serialize_strbuf() untracked cache: don't open non-existent .gitignore untracked cache: mark what dirs should be recursed/saved untracked cache: record/validate dir mtime and reuse cached output untracked cache: make a wrapper around {open,read,close}dir() ...
2015-05-22remote.c: return upstream name from stat_tracking_infoLibravatar Jeff King1-12/+6
After calling stat_tracking_info, callers often want to print the name of the upstream branch (in addition to the tracking count). To do this, they have to access branch->merge->dst[0] themselves. This is not wrong, as the return value from stat_tracking_info tells us whether we have an upstream branch or not. But it is a bit leaky, as we make an assumption about how it calculated the upstream name. Instead, let's add an out-parameter that lets the caller know the upstream name we found. As a bonus, we can get rid of the unusual tri-state return from the function. We no longer need to use it to differentiate between "no tracking config" and "tracking ref does not exist" (since you can check the upstream_name for that), so we can just use the usual 0/-1 convention for success/error. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-14Merge branch 'sb/plug-wt-shortstatus-tracking-leak'Libravatar Junio C Hamano1-0/+1
* sb/plug-wt-shortstatus-tracking-leak: wt-status.c: fix a memleak
2015-03-30wt-status.c: fix a memleakLibravatar Stefan Beller1-0/+1
wt_shortstatus_print_tracking() calls shorten_unambiguous_ref(), which returns a newly allocated memory the caller takes ownership of; it is necessary to free `base` when the function is done with it. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25Merge branch 'jk/run-command-capture'Libravatar Junio C Hamano1-7/+3
The run-command interface was easy to abuse and make a pipe for us to read from the process, wait for the process to finish and then attempt to read its output, which is a pattern that lead to a deadlock. Fix such uses by introducing a helper to do this correctly (i.e. we need to read first and then wait the process to finish) and also add code to prevent such abuse in the run-command helper. * jk/run-command-capture: run-command: forbid using run_command with piped output trailer: use capture_command submodule: use capture_command wt-status: use capture_command run-command: introduce capture_command helper wt_status: fix signedness mismatch in strbuf_read call wt-status: don't flush before running "submodule status"
2015-03-22wt-status: use capture_commandLibravatar Jeff King1-4/+1
When we spawn "git submodule status" to read its output, we use run_command() followed by strbuf_read() read from the pipe. This can deadlock if the subprocess output is larger than the system pipe buffer. Furthermore, if start_command() fails, we'll try to read from a bogus descriptor (probably "-1" or a descriptor we just closed, but it is a bad idea for us to make assumptions about how start_command implements its error handling). And if start_command succeeds, we leak the file descriptor for the pipe to the child. All of these can be solved by using the capture_command helper. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-22wt_status: fix signedness mismatch in strbuf_read callLibravatar Jeff King1-3/+3
We call strbuf_read(), and want to know whether we got any output. To do so, we assign the result to a size_t, and check whether it is non-zero. But strbuf_read returns a signed ssize_t. If it encounters an error, it will return -1, and we'll end up treating this the same as if we had gotten output. Instead, we can just check whether our buffer has anything in it (which is what we care about anyway, and is the same thing since we know the buffer was empty to begin with). Note that the "len" variable actually has two roles in this function. Now that we've eliminated the first, we can push the declaration closer to the point of use for the second one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-22wt-status: don't flush before running "submodule status"Libravatar Jeff King1-1/+0
This is a holdover from the original implementation in ac8d5af (builtin-status: submodule summary support, 2008-04-12), which just had the sub-process output to our descriptor; we had to make sure we had flushed any data that we produced before it started writing. Since 3ba7407 (submodule summary: ignore --for-status option, 2013-09-06), however, we pipe the sub-process output back to ourselves. So there's no longer any need to flush (it does not hurt, but it may leave readers wondering why we do it). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20Merge branch 'mg/detached-head-report'Libravatar Junio C Hamano1-3/+3
"git branch" on a detached HEAD always said "(detached from xyz)", even when "git status" would report "detached at xyz". The HEAD is actually at xyz and haven't been moved since it was detached in such a case, but the user cannot read what the current value of HEAD is when "detached from" is used. * mg/detached-head-report: branch: name detached HEAD analogous to status wt-status: refactor detached HEAD analysis
2015-03-17Merge branch 'mg/status-v-v'Libravatar Junio C Hamano1-0/+20
"git status" now allows the "-v" to be given twice to show the differences that are left in the working tree not to be committed. * mg/status-v-v: commit/status: show the index-worktree diff with -v -v t7508: test git status -v t7508: .gitignore 'expect' and 'output' files
2015-03-12status: enable untracked cacheLibravatar Nguyễn Thái Ngọc Duy1-0/+2
update_index_if_able() is moved down so that the updated untracked cache could be written out. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06wt-status: refactor detached HEAD analysisLibravatar Michael J Gruber1-3/+3
wt_status_print() is the only caller of wt_status_get_detached_from(). The latter performs most of the analysis of a detached HEAD, including finding state->detached_from; the caller checks whether the detached HEAD is still at state->detached_from or has moved away. Move that last bit of analysis to wt_status_get_detached_from(), too, and store the boolean result in state->detached_at. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06commit/status: show the index-worktree diff with -v -vLibravatar Michael J Gruber1-0/+20
git commit and git status in long format show the diff between HEAD and the index when given -v. This allows previewing a commit to be made. They also list tracked files with unstaged changes, but without a diff. Introduce '-v -v' which shows the diff between the index and the worktree in addition to the HEAD index diff. This allows a review of unstaged changes which might be missing from the commit. In the case of '-v -v', additonal header lines Changes to be committed: and Changes not staged for commit: are inserted before the diffs, which are equal to those in the status part; the latter preceded by 50*"-" to make it stick out more. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-24Merge branch 'jk/status-read-branch-name-fix' into maintLibravatar Junio C Hamano1-1/+1
Code to read branch name from various files in .git/ directory would have misbehaved if the code to write them left an empty file. * jk/status-read-branch-name-fix: read_and_strip_branch: fix typo'd address-of operator
2015-02-17Merge branch 'jk/status-read-branch-name-fix'Libravatar Junio C Hamano1-1/+1
Code to read branch name from various files in .git/ directory would have misbehaved if the code to write them left an empty file. * jk/status-read-branch-name-fix: read_and_strip_branch: fix typo'd address-of operator
2015-01-28read_and_strip_branch: fix typo'd address-of operatorLibravatar Jeff King1-1/+1
When we are chomping newlines from the end of a strbuf, we must check "sb.len != 0" before accessing "sb.buf[sb.len - 1]". However, this code mistakenly checks "&sb.len", which is always true (it is a part of an auto struct, so the address is always non-zero). This could lead to us accessing memory outside the strbuf when we read an empty file. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-10use args member of struct child_processLibravatar René Scharfe1-10/+7
Convert users of struct child_process to using the managed argv_array args instead of providing their own. This shortens the code a bit and ensures that the allocated memory is released automatically after use. Suggested-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>
2014-10-24Merge branch 'rs/run-command-env-array'Libravatar Junio C Hamano1-4/+2
Add managed "env" array to child_process to clarify the lifetime rules. * rs/run-command-env-array: use env_array member of struct child_process run-command: add env_array, an optional argv_array for env
2014-10-19use env_array member of struct child_processLibravatar René Scharfe1-4/+2
Convert users of struct child_process to using the managed env_array for specifying environment variables instead of supplying an array on the stack or bringing their own argv_array. This shortens and simplifies the code and ensures automatically that the allocated memory is freed after use. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15refs.c: change resolve_ref_unsafe reading argument to be a flags fieldLibravatar Ronnie Sahlberg1-1/+1
resolve_ref_unsafe takes a boolean argument for reading (a nonexistent ref resolves successfully for writing but not for reading). Change this to be a flags field instead, and pass the new constant RESOLVE_REF_READING when we want this behaviour. While at it, swap two of the arguments in the function to put output arguments at the end. As a nice side effect, this ensures that we can catch callers that were unaware of the new API so they can be audited. Give the wrapper functions resolve_refdup and read_ref_full the same treatment for consistency. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-20run-command: introduce CHILD_PROCESS_INITLibravatar René Scharfe1-2/+1
Most struct child_process variables are cleared using memset first after declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to initialize them statically instead. That's shorter, doesn't require a function call and is slightly more readable (especially given that we already have STRBUF_INIT, ARGV_ARRAY_INIT etc.). Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-22Merge branch 'kb/perf-trace'Libravatar Junio C Hamano1-11/+3
* kb/perf-trace: api-trace.txt: add trace API documentation progress: simplify performance measurement by using getnanotime() wt-status: simplify performance measurement by using getnanotime() git: add performance tracing for git's main() function to debug scripts trace: add trace_performance facility to debug performance issues trace: add high resolution timer function to debug performance issues trace: add 'file:line' to all trace output trace: move code around, in preparation to file:line output trace: add current timestamp to all trace output trace: disable additional trace output for unit tests trace: add infrastructure to augment trace output with additional info sha1_file: change GIT_TRACE_PACK_ACCESS logging to use trace API Documentation/git.txt: improve documentation of 'GIT_TRACE*' variables trace: improve trace performance trace: remove redundant printf format attribute trace: consistently name the format parameter trace: move trace declarations from cache.h to new trace.h
2014-07-13wt-status: simplify performance measurement by using getnanotime()Libravatar Karsten Blees1-11/+3
Calculating duration from a single uint64_t is simpler than from a struct timeval. Change performance measurement for 'advice.statusuoption' from gettimeofday() to getnanotime(). Also initialize t_begin to prevent uninitialized variable warning. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-10Merge branch 'rs/status-code-clean-up'Libravatar Junio C Hamano1-8/+5
* rs/status-code-clean-up: wt-status: simplify building of summary limit argument wt-status: use argv_array for environment
2014-06-29wt-status: simplify building of summary limit argumentLibravatar René Scharfe1-3/+1
Use argv_array_pushf for building the number string for the option --summary-limit directly instead of using an intermediate buffer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-29wt-status: use argv_array for environmentLibravatar René Scharfe1-5/+4
Instead of using a PATH_MAX buffer, use argv_array for constructing the environment for git submodule summary. This simplifies the code a bit and removes the arbitrary length limit. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-25Merge branch 'jl/status-added-submodule-is-never-ignored' into maintLibravatar Junio C Hamano1-1/+11
"git status" (and "git commit") behaved as if changes in a modified submodule are not there if submodule.*.ignore configuration is set, which was misleading. The configuration is only to unclutter diff output during the course of development, and should not to hide changes in the "status" output to cause the users forget to commit them. * jl/status-added-submodule-is-never-ignored: commit -m: commit staged submodules regardless of ignore config status/commit: show staged submodules regardless of ignore config
2014-06-16Merge branch 'jl/status-added-submodule-is-never-ignored'Libravatar Junio C Hamano1-1/+11
submodule.*.ignore and diff.ignoresubmodules are used to ignore all submodule changes in "diff" output, but it can be confusing to apply these configuration values to status and commit. This is a backward-incompatible change, but should be so in a good way (aka bugfix). * jl/status-added-submodule-is-never-ignored: commit -m: commit staged submodules regardless of ignore config status/commit: show staged submodules regardless of ignore config
2014-06-06Merge branch 'fc/status-printf-squelch-format-zero-length-warnings'Libravatar Junio C Hamano1-11/+11
* fc/status-printf-squelch-format-zero-length-warnings: silence a bunch of format-zero-length warnings
2014-05-07silence a bunch of format-zero-length warningsLibravatar Felipe Contreras1-11/+11
This can be observed in many versions of gcc and still exists with 4.9.0: wt-status.c: In function ‘wt_status_print_unmerged_header’: wt-status.c:191:2: warning: zero-length gnu_printf format string [-Wformat-zero-length] status_printf_ln(s, c, ""); ^ The user have long been told to pass -Wno-format-zero-length, but a patch that avoids warning altogether is not too noisy, so let's do so. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-07status/commit: show staged submodules regardless of ignore configLibravatar Jens Lehmann1-1/+11
Currently setting submodule.<name>.ignore and/or diff.ignoreSubmodules to "all" suppresses all output of submodule changes for the diff family, status and commit. For status and commit this is really confusing, as it even when the user chooses to record a new commit for an ignored submodule by adding it manually this change won't show up under the to-be-committed changes. To add insult to injury, a later "git commit" will error out with "nothing to commit" when only ignored submodules are staged. Fix that by making wt_status always print staged submodule changes, no matter what ignore settings are configured. The only exception is when the user explicitly uses the "--ignore-submodules=all" command line option, in that case the submodule output is still suppressed. This also makes "git commit" work again when only modifications of ignored submodules are staged, as that command uses the "commitable" member of the wt_status struct to determine if staged changes are present. But this only happens when the commit command uses the wt_status* functions to produce status output for human consumption (when forking an editor or with --dry-run), in all other cases (e.g. when run in a script with '-m') another code path is taken which uses index_differs_from() to determine if any changes are staged which still ignores submodules according to their configuration. This will be fixed in a follow-up commit. Change t7508 to reflect this new behavior and add three new tests to show that a single staged submodule configured to be ignored will be committed when the status output is generated and won't be if not. Also update the documentation of the ignore config options accordingly. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>