This is the logical equivalent for "git status" of 3ee4452 (bash: teach
__git_ps1 about REVERT_HEAD).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tb/document-status-u-tradeoff:
status: advise to consider use of -u when read_directory takes too long
git status: document trade-offs in choosing parameters to the -u option
Add a bit more information to "git status" during a rebase/bisect
session.
* nd/branch-show-rebase-bisect-state:
status, branch: fix the misleading "bisecting" message
branch: show more information when HEAD is detached
status: show more info than "currently not on any branch"
wt-status: move wt_status_get_state() out to wt_status_print()
wt-status: split wt_status_state parsing function out
wt-status: move strbuf into read_and_strip_branch()
The current message is "bisecting %s" (or "bisecting branch %s").
"%s" is the current branch when we started bisecting. Clarify that to
avoid confusion with good and bad refs passed to "bisect" command.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
diff.c: diff.renamelimit => diff.renameLimit in message
wt-status: fix possible use of uninitialized variable
fast-import: clarify "inline" logic in file_change_m
run-command: always set failed_errno in start_command
transport: drop "int cmp = cmp" hack
drop some obsolete "x = x" compiler warning hacks
fast-import: use pointer-to-pointer to keep list tail
In wt_status_print_change_data, we accept a change_type flag
that is meant to be either WT_STATUS_UPDATED or
WT_STATUS_CHANGED. We then switch() on this value to set
the local variable "status" for each case, but do not
provide a fallback "default" label to the switch statement.
As a result, the compiler realizes that "status" might be
unset, and complains with a warning. To silence this
warning, we use the "int status = status" trick. This is
correct with the current code, as all callers provide one of
the two expected change_type flags. However, it's also a
maintenance trap, as there is nothing to prevent future
callers from passing another flag, nor to document this
assumption.
Instead of using the "x = x" hack, let's handle the default
case in the switch() statement with a die("BUG"). That tells
the compiler and any readers of the code exactly what the
function's input assumptions are.
We could also convert the flag to an enum, which would
provide a compile-time check on the function input. However,
since these flags are part of a larger enum, that would make
the code unnecessarily complex (we would have to make a new
enum with just the two flags, and then convert it to the old
enum for passing to sub-functions).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suggest users to look into using--untracked=no option when "git
status" takes too long.
* tb/document-status-u-tradeoff:
status: advise to consider use of -u when read_directory takes too long
git status: document trade-offs in choosing parameters to the -u option
When a remote ref or a tag is checked out, HEAD is automatically
detached. There is no user-friendly way to find out what ref is
checked out in this case. This patch digs in reflog for this
information and shows "HEAD detached from origin/master" or "HEAD
detached at v1.8.0" instead of "currently not on any branch".
When it cannot figure out the original ref, it shows an abbreviated
SHA-1. "Currently not on any branch" would never display (unless
reflog is pruned to near empty that the last checkout entry is lost).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The strbufs are placed outside read_and_strip_branch as a premature
optimization: when it reads "refs/heads/foo" to strbuf and wants to
return just "foo", it could do so without memory movement. In return
the caller must not use the returned pointer after releasing strbufs,
which own the buffers that contain the returned strings. It's a clumsy
design.
By moving strbufs into read_and_strip_branch(), the returned pointer
always points to a malloc'd buffer or NULL. The pointer can be passed
around and freed after use.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce advice.statusUoption to suggest considering use of -u to
strike different trade-off when it took more than 2 seconds to
enumerate untracked/ignored files.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The typical use-case is starting a rebase, do something else, come
back the day after, run "git status" or make a new commit and wonder
what in the world's going on. Which branch is being rebased is
probably the most useful tidbit to help, but the target may help
too.
Ideally, I would have loved to see "rebasing master on
origin/master", but the target ref name is not stored during rebase,
so this patch writes "rebasing master on a78c8c98b" as a
half-measure to remind future users of that potential improvement.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow a configuration variable core.commentchar to customize the
character used to comment out the hint lines in the edited text from
the default '#'.
* jc/custom-comment-char:
Allow custom "comment char"
Some users do want to write a line that begin with a pound sign, #,
in their commit log message. Many tracking system recognise
a token of #<bugid> form, for example.
The support we offer these use cases is not very friendly to the end
users. They have a choice between
- Don't do it. Avoid such a line by rewrapping or indenting; and
- Use --cleanup=whitespace but remove all the hint lines we add.
Give them a way to set a custom comment char, e.g.
$ git -c core.commentchar="%" commit
so that they do not have to do either of the two workarounds.
[jc: although I started the topic, all the tests and documentation
updates, many of the call sites of the new strbuf_add_commented_*()
functions, and the change to git-submodule.sh scripted Porcelain are
from Ralf.]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Output from "git status --ignored" showed an unexpected interaction
with "--untracked".
* ap/status-ignored-in-ignored-directory:
status: always report ignored tracked directories
git-status: Test --ignored behavior
dir.c: Make git-status --ignored more consistent
The current behavior of git-status is inconsistent and misleading.
Especially when used with --untracked-files=all option:
- files ignored in untracked directories will be missing from
status output.
- untracked files in committed yet ignored directories are also
missing.
- with --untracked-files=normal, untracked directories that
contains only ignored files are dropped too.
Make the behavior more consistent across all possible use cases:
- "--ignored --untracked-files=normal" doesn't show each specific
files but top directory. It instead shows untracked directories
that only contains ignored files, and ignored tracked directories
with untracked files.
- "--ignored --untracked-files=all" shows all ignored files, either
because it's in an ignored directory (tracked or untracked), or
because the file is explicitly ignored.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"%s files" gives no sense what "%s" might be. Give translators full
phrases.
"blah blah blah%s\n" where %s is another sentence does not show the real
length of full line. As a result, l10n messages may exceed 80 columns
unintentionally. Make it two sentences.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "status" command recently learned to describe the
in-progress operation in its long output format (e.g.,
rebasing, am, etc). This message gets its own slot in the
color table, even though it is not configurable. As a
result, if the user has set color.status.header to a
non-default value, this message will not match (and cannot
be made to match, as there is no config option).
It is probably more sane to just color it like the rest of
the text (i.e., just use color.status.header). This would
not allow users to customize the color of this message
independently, but they cannot do that with the current code
anyway, and if somebody wants to build customizable
colorization later, this patch does not make it much harder
to do so.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add new informative help messages at the output of 'git status' when
the user is splitting a commit. The code figures this state by
comparing the contents of the following files in the .git/ directory:
- HEAD
- ORIG_HEAD
- rebase-merge/amend
- rebase-merge/orig-head
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The display of the advice '(use git add/rm [...])' (when there are
unmerged files) after running 'git status' is now depending of the
mark, whether it's 'both deleted', 'deleted by us/them' or others. For
instance, when there is just one file that's marked as 'both deleted',
'git status' shows '(use git rm [...])' and if there are two files,
one as 'both deleted' and the other as 'added by them', the advice is
'(use git add/rm [...])'.
The previous tests in t7512-status-help.sh are updated.
Test about the case of only 'both deleted' is added in
t7060-wtstatus.sh
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch provides new informative help messages in the display of
'git status' (at the top) during conflicts, rebase, am, bisect or
cherry-pick process.
The new messages are not shown when using options such as -s or
--porcelain. The messages about the current situation of the user are
always displayed but the advices on what the user needs to do in order
to resume a rebase/bisect/am/commit after resolving conflicts can be
hidden by setting advice.statushints to 'false' in the config file.
Thus, information about the updated advice.statushints key are added
in Documentation/config.txt.
Also, the test t7060-wt-status.sh is now working with the new help
messages. Tests about suggestions of "git rm" are also added.
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no reason not to, as the user has to explicitly ask
for it, so we are not breaking compatibility by doing so. We
can do this simply by moving the "show_branch" flag into
the wt_status struct. As a bonus, this saves us from passing
it explicitly, simplifying the code.
Signed-off-by: Jeff King <peff@peff.net>
When the "-z" option is given to status, we are supposed to
NUL-terminate each record. However, the "-b" code to show
the tracking branch did not respect this, and always ended
with a newline.
Signed-off-by: Jeff King <peff@peff.net>
This option is passed separately to the wt_status printing
functions, whereas every other formatting option is
contained in the wt_status struct itself. Let's do the same
here, so we can avoid passing it around through the call
stack.
Signed-off-by: Jeff King <peff@peff.net>
* jk/color-and-pager:
want_color: automatically fallback to color.ui
diff: don't load color config in plumbing
config: refactor get_colorbool function
color: delay auto-color decision until point of use
git_config_colorbool: refactor stdout_is_tty handling
diff: refactor COLOR_DIFF from a flag into an int
setup_pager: set GIT_PAGER_IN_USE
t7006: use test_config helpers
test-lib: add helper functions for config
t7006: modernize calls to unset
Conflicts:
builtin/commit.c
parse-options.c
When we read a color value either from a config file or from
the command line, we use git_config_colorbool to convert it
from the tristate always/never/auto into a single yes/no
boolean value.
This has some timing implications with respect to starting
a pager.
If we start (or decide not to start) the pager before
checking the colorbool, everything is fine. Either isatty(1)
will give us the right information, or we will properly
check for pager_in_use().
However, if we decide to start a pager after we have checked
the colorbool, things are not so simple. If stdout is a tty,
then we will have already decided to use color. However, the
user may also have configured color.pager not to use color
with the pager. In this case, we need to actually turn off
color. Unfortunately, the pager code has no idea which color
variables were turned on (and there are many of them
throughout the code, and they may even have been manipulated
after the colorbool selection by something like "--color" on
the command line).
This bug can be seen any time a pager is started after
config and command line options are checked. This has
affected "git diff" since 89d07f7 (diff: don't run pager if
user asked for a diff style exit code, 2007-08-12). It has
also affect the log family since 1fda91b (Fix 'git log'
early pager startup error case, 2010-08-24).
This patch splits the notion of parsing a colorbool and
actually checking the configuration. The "use_color"
variables now have an additional possible value,
GIT_COLOR_AUTO. Users of the variable should use the new
"want_color()" wrapper, which will lazily determine and
cache the auto-color decision.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This lets us store more than just a bit flag for whether we
want color; we can also store whether we want automatic
colors. This can be useful for making the automatic-color
decision closer to the point of use.
This mostly just involves replacing DIFF_OPT_* calls with
manipulations of the flag. The biggest exception is that
calls to DIFF_OPT_TST must check for "o->use_color > 0",
which lets an "unknown" value (i.e., the default) stay at
"no color". In the previous code, a value of "-1" was not
propagated at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 1b908b6 (wt-status: rename and restructure
status-print-untracked, 2010-04-10) converted the
wt_status_print_untracked function into
wt_status_print_other, taking a string_list of either
untracked or ignored items to print. However, the "nothing
to show" early return still checked the wt_status->untracked
list instead of the passed-in list.
That meant that if we had ignored items to show, but no
untracked items, we would erroneously exit early and fail to
show the ignored items.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Gettextize the "renamed: %s -> %s" message which appears as part of
git-status(1) output. Two tests in t4001-diff-rename.sh explicitly
checked for this message. Change them to skip under
GETTEXT_POISON=YesPlease.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Gettextize the "# Initial commit" message. A test in t7501-commit.sh
explicitly checked for this message. Change it to skip under
GETTEXT_POISON=YesPlease.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Gettextize the "# Changes to be committed:" messages. Several tests
explicitly checked for this message. Change them to skip under
GETTEXT_POISON=YesPlease.
Since these tests didn't check for the rest of the git-status(1)
output this change has been split up from the "git-status basic
messages" patch.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the messages added in v1.7.2-rc0~54^2~1 translatable. Some of
these could use the to be implemented plural support in the gettext
library.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Gettextize the "nothing to commit" messages. Many tests explicitly
checked for this message. Change them to skip under
GETTEXT_POISON=YesPlease.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Gettextize the most common git-status messages. Many tests checked for
these explicitly. Change them to skip under GETTEXT_POISON=YesPlease.
Some of the tests in t7508-status.sh needed to be split up when I
added C_LOCALE_OUTPUT to them, since parts of them affected later
tests (some of which aren't being skipped) indirectly.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status code is used to provide a reminder of changes included and
not included for the commit message template opened in the operator's
text editor by "git commit". Therefore each line of its output begins
with the comment character "#":
# Please enter the commit message for your changes. Lines starting
Use the new status_printf{,_ln,_more} functions to take care of adding
"#" to the beginning of such status lines automatically. Using these
will have two advantages over the current code:
- The obvious one is to force separation of the "#" from the
translatable part of the message when git learns to translate its
output.
- Another advantage is that this makes it easier for us to drop "#"
prefix in "git status" output in later versions of git if we want
to.
Explained-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce status_printf{,_ln,_more} wrapper functions around
color_vfprintf() which take care of adding "#" to the beginning of
status lines automatically. The semantics:
- status_printf() is just like color_fprintf() but it adds a "# "
at the beginning of each line of output;
- status_printf_ln() is a convenience function that additionally
adds "\n" at the end;
- status_printf_more() is a variant of status_printf() used to
continue lines that have already started. It suppresses the "#" at
the beginning of the first line.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status code is used to provide a reminder of changes included and
not included for the commit message template opened in the operator's
text editor by "git commit". Therefore each line of its output begins
with the comment character "#":
# Please enter the commit message for your changes. Lines starting
Use the new status_printf{,_ln,_more} functions to take care of adding
"#" to the beginning of such status lines automatically. Using these
will have two advantages over the current code:
- The obvious one is to force separation of the "#" from the
translatable part of the message when git learns to translate its
output.
- Another advantage is that this makes it easier for us to drop "#"
prefix in "git status" output in later versions of git if we want
to.
Explained-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce status_printf{,_ln,_more} wrapper functions around
color_vfprintf() which take care of adding "#" to the beginning of
status lines automatically. The semantics:
- status_printf() is just like color_fprintf() but it adds a "# "
at the beginning of each line of output;
- status_printf_ln() is a convenience function that additionally
adds "\n" at the end;
- status_printf_more() is a variant of status_printf() used to
continue lines that have already started. It suppresses the "#" at
the beginning of the first line.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously the user was advised to use commit -c CHERRY_PICK_HEAD after
a conflicting cherry-pick. While this would preserve the original
commit's authorship, it would sadly discard cherry-pick's carefully
crafted MERGE_MSG (which contains the list of conflicts as well as the
original commit-id in the case of cherry-pick -x).
On the other hand, if a bare 'commit' were performed, it would preserve
the MERGE_MSG while resetting the authorship.
In other words, there was no way to simultaneously take the authorship
from CHERRY_PICK_HEAD and the commit message from MERGE_MSG.
This change fixes that situation. A bare 'commit' will now take the
authorship from CHERRY_PICK_HEAD and the commit message from MERGE_MSG.
If the user wishes to reset authorship, that must now be done explicitly
via --reset-author.
A side-benefit of passing commit authorship along this way is that we
can eliminate redundant authorship parsing code from revert.c.
(Also removed an unused include from revert.c)
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This gives it the same behavior as we had prior to 1d28232
(status: show branchname with a configurable color).
To do this we need the concept of a "NIL" color, which is
provided by color.[ch]. The implementation is very simple;
in particular, there are no precautions taken against code
accidentally printing the NIL. This should be fine in
practice because:
1. You can't input a NIL color in the config, so it must
come from the in-code defaults. Which means it is up
the client code to handle the NILs it defines.
2. If we do ever print a NIL, it will be obvious what the
problem is, and the bug can be fixed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
You can tell "git status" to paint the name of the current branch in its
output (the line that says "On branch ...") by setting the configuration
variable color.status.branch; it is by default turned off.
Signed-off-by: Aleksi Aalto <aga@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to the documentation for git-status, in short-format mode,
paths with spaces or unprintable characters are quoted. However
28fba29 (Do not quote SP., 2005-10-17) removed the behavior that quotes
paths that have spaces but not unprintable characters. Unfortunately this
makes the output of `git status --porcelain` non-parseable in certain
(rather unusual) edge cases. In the interest of removing ambiguity when
parsing the output of `git status --porcelain`, restore the behavior of
quoting paths with spaces in git-status's short-format mode.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Older Gits talked about "updating" a file to add its content to the
index, but this terminology is confusing for new users. "to stage" is far
more intuitive and already used in e.g. the "git stage" command name.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When iterating through the list of directory entries, searching for
untracked entries, only the entries added to the string_list were free'd.
The rest (tracked or not matching the pathspec) were leaked.
Ditto for the "ignored" loop.
Rearrange the loops so that all entries are free'd.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new "ignore" config option controls the default behavior for "git
status" and the diff family. It specifies under what circumstances they
consider submodules as modified and can be set separately for each
submodule.
The command line option "--ignore-submodules=" has been extended to accept
the new parameter "none" for both status and diff.
Users that chose submodules to get rid of long work tree scanning times
might want to set the "dirty" option for those submodules. This brings
back the pre 1.7.0 behavior, where submodule work trees were never
scanned for modifications. By using "--ignore-submodules=none" on the
command line the status and diff commands can be told to do a full scan.
This option can be set to the following values (which have the same name
and meaning as for the "--ignore-submodules" option of status and diff):
"all": All changes to the submodule will be ignored.
"dirty": Only differences of the commit recorded in the superproject and
the submodules HEAD will be considered modifications, all changes
to the work tree of the submodule will be ignored. When using this
value, the submodule will not be scanned for work tree changes at
all, leading to a performance benefit on large submodules.
"untracked": Only untracked files in the submodules work tree are ignored,
a changed HEAD and/or modified files in the submodule will mark it
as modified.
"none" (which is the default): Either untracked or modified files in a
submodules work tree or a difference between the subdmodules HEAD
and the commit recorded in the superproject will make it show up
as changed. This value is added as a new parameter for the
"--ignore-submodules" option of the diff family and "git status"
so the user can override the settings in the configuration.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jl/status-ignore-submodules:
Add the option "--ignore-submodules" to "git status"
git submodule: ignore dirty submodules for summary and status
Conflicts:
builtin/commit.c
t/t7508-status.sh
wt-status.c
wt-status.h
* jp/string-list-api-cleanup:
string_list: Fix argument order for string_list_append
string_list: Fix argument order for string_list_lookup
string_list: Fix argument order for string_list_insert_at_index
string_list: Fix argument order for string_list_insert
string_list: Fix argument order for for_each_string_list
string_list: Fix argument order for print_string_list
Update the definition and callers of string_list_insert to use the
string_list as the first argument. This helps make the string_list
API easier to use by being more consistent.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some use cases it is not desirable that "git status" considers
submodules that only contain untracked content as dirty. This may happen
e.g. when the submodule is not under the developers control and not all
build generated files have been added to .gitignore by the upstream
developers. Using the "untracked" parameter for the "--ignore-submodules"
option disables checking for untracked content and lets git diff report
them as changed only when they have new commits or modified content.
Sometimes it is not wanted to have submodules show up as changed when they
just contain changes to their work tree (this was the behavior before
1.7.0). An example for that are scripts which just want to check for
submodule commits while ignoring any changes to the work tree. Also users
having large submodules known not to change might want to use this option,
as the - sometimes substantial - time it takes to scan the submodule work
tree(s) is saved when using the "dirty" parameter.
And if you want to ignore any changes to submodules, you can now do that
by using this option without parameters or with "all" (when the config
option status.submodulesummary is set, using "all" will also suppress the
output of the submodule summary).
A new function handle_ignore_submodules_arg() is introduced to parse this
option new to "git status" in a single location, as "git diff" already
knew it.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gv/portable:
test-lib: use DIFF definition from GIT-BUILD-OPTIONS
build: propagate $DIFF to scripts
Makefile: Tru64 portability fix
Makefile: HP-UX 10.20 portability fixes
Makefile: HPUX11 portability fixes
Makefile: SunOS 5.6 portability fix
inline declaration does not work on AIX
Allow disabling "inline"
Some platforms lack socklen_t type
Make NO_{INET_NTOP,INET_PTON} configured independently
Makefile: some platforms do not have hstrerror anywhere
git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition
test_cmp: do not use "diff -u" on platforms that lack one
fixup: do not unconditionally disable "diff -u"
tests: use "test_cmp", not "diff", when verifying the result
Do not use "diff" found on PATH while building and installing
enums: omit trailing comma for portability
Makefile: -lpthread may still be necessary when libc has only pthread stubs
Rewrite dynamic structure initializations to runtime assignment
Makefile: pass CPPFLAGS through to fllow customization
Conflicts:
Makefile
wt-status.h
This patch adds a first line in the output of `git status -s` when given
the option `-b` or `--branch`, showing which branch the user is
currently on, and in case of tracking branches the number of commits on
each branch.
Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unfortunately, there are still plenty of production systems with
vendor compilers that choke unless all compound declarations can be
determined statically at compile time, for example hpux10.20 (I can
provide a comprehensive list of our supported platforms that exhibit
this problem if necessary).
This patch simply breaks apart any compound declarations with dynamic
initialisation expressions, and moves the initialisation until after
the last declaration in the same block, in all the places necessary to
have the offending compilers accept the code.
Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, status gives a lot of hints even when advice.statusHints is
false. Change this so that all hints depend on the config variable.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
color_fprintf() has the same function signature as fprintf() and newer
gcc warns when a non-constant string is fed as the format
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jl/submodule-diff-dirtiness:
git status: ignoring untracked files must apply to submodules too
git status: Fix false positive "new commits" output for dirty submodules
Refactor dirty submodule detection in diff-lib.c
git status: Show detailed dirty status of submodules in long format
git diff --submodule: Show detailed dirty status of submodules
Since 1.7.0 submodules are considered dirty when they contain untracked
files. But when git status is called with the "-uno" option, the user
asked to ignore untracked files, so they must be ignored in submodules
too. To achieve this, the new flag DIFF_OPT_IGNORE_UNTRACKED_IN_SUBMODULES
is introduced.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So far the last parameter to setup_revisions() was to specify the default
ref when the command line did not give any (typically "HEAD"). This changes
it to take a pointer to a structure so that we can add other information without
touching too many codepaths in later patches.
There is no functionality change.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 1.7.0 there are three reasons a submodule is considered modified
against the work tree: It contains new commits, modified content or
untracked content. Lets show all reasons in the long format of git status,
so the user can better asses the nature of the modification. This change
does not affect the short and porcelain formats.
Two new members are added to "struct wt_status_change_data" to store the
information gathered by run_diff_files(). wt-status.c uses the new flag
DIFF_OPT_DIRTY_SUBMODULES to tell diff-lib.c it wants to get detailed
dirty information about submodules.
A hint line for submodules is printed in the dirty header when dirty
submodules are present.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jl/submodule-diff:
Performance optimization for detection of modified submodules
git status: Show uncommitted submodule changes too when enabled
Teach diff that modified submodule directory is dirty
Show submodules as modified when they contain a dirty work tree
When the configuration variable status.submodulesummary is not 0 or
false, "git status" shows the submodule summary of the staged submodule
commits. But it did not show the summary of those commits not yet
staged in the supermodule, making it hard to see what will not be
committed.
The output of "submodule summary --for-status" has been changed from
"# Modified submodules:" to "# Submodule changes to be committed:" for
the already staged changes. "# Submodules changed but not updated:" has
been added for changes that will not be committed. This is much clearer
and consistent with the output for regular files.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch gets rid of whole-tree cache refresh and untracked file
search. Instead only specified path will be looked at.
Again some numbers on gentoo-x86, ~80k files:
Unmodified Git:
$ time git st eclass/
nothing to commit (working directory clean)
real 0m3.211s
user 0m1.977s
sys 0m1.135s
Modified Git:
$ time ~/w/git/git st eclass/
nothing to commit (working directory clean)
real 0m1.587s
user 0m1.426s
sys 0m0.111s
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/1.7.0-status:
status/commit: do not suggest "reset HEAD <path>" while merging
commit/status: "git add <path>" is not necessarily how to resolve
commit/status: check $GIT_DIR/MERGE_HEAD only once
t7508-status: test all modes with color
t7508-status: status --porcelain ignores relative paths setting
status: reduce duplicated setup code
status: disable color for porcelain format
status -s: obey color.status
builtin-commit: refactor short-status code into wt-status.c
t7508-status.sh: Add tests for status -s
status -s: respect the status.relativePaths option
docs: note that status configuration affects only long format
commit: support alternate status formats
status: add --porcelain output format
status: refactor format option parsing
status: refactor short-mode printing to its own function
status: typo fix in usage
git status: not "commit --dry-run" anymore
git stat -s: short status output
git stat: the beginning of "status that is not a dry-run of commit"
Conflicts:
t/t4034-diff-words.sh
wt-status.c
Suggesting "'reset HEAD <path>' to unstage" is dead wrong if we are about
to record a merge commit. For either an unmerged path (i.e. with
unresolved conflicts), or an updated path, it would result in discarding
what the other branch did.
Note that we do not do anything special in a case where we are amending a
merge. The user is making an evil merge starting from an already
committed merge, and running "reset HEAD <path>" is the right way to get
rid of the local edit that has been added to the index.
Once "reset --unresolve <path>" becomes available, we might want to
suggest it for a merged path that has unresolve information, but until
then, just remove the incorrect advice.
We might also want to suggest "checkout --conflict <path>" to revert the
file in the work tree to the state of failed automerge for an unmerged
path, but we never did that, and this commit does not change that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the desired resolution is to remove the path, "git rm <path>" is the
command the user needs to use. Just like in "Changed but not updated"
section, suggest to use "git add/rm" as appropriate.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have three output formats: short, porcelain, and long.
The short and long formats respect user-config, and the
porcelain one does not. This led to us repeating
config-related setup code for the short and long formats.
Since the last commit, color config is explicitly cleared
when showing the porcelain format. Let's do the same with
relative-path configuration, which enables us to hoist the
duplicated code from the switch statement in cmd_status.
As a bonus, this fixes "commit --dry-run --porcelain", which
was unconditionally setting up that configuration, anyway.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The porcelain format is identical to the shortstatus format,
except that it should not respect any user configuration,
including color.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the short version of status obey the color.status boolean. We color
the status letters only, because they carry the state information and are
potentially colored differently, such as for a file with staged changes
as well as changes in the worktree against the index.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, builtin-commit.c contains most code producing the
short-status output, whereas wt-status.c contains most of the code for
the long format.
Refactor so that most of the long and short format producing code
resides in wt-status.c and is named analogously.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These messages are nice for new users, but experienced git
users know how to manipulate the index, and these messages
waste a lot of screen real estate.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When resolving a conflicted merge, two lists in the status output need
more attention from the user than other parts.
- the list of updated paths is useful to review the amount of changes the
merge brings in (the user cannot do much about them other than
reviewing, though); and
- the list of unmerged paths needs the most attention from the user; the
user needs to resolve them in order to proceed.
Since the output of git status does not by default go through the pager,
the early parts of the output can scroll away at the top. It is better to
put the more important information near the bottom. During a merge, local
changes that are not in the index are minimum, and you should keep the
untracked list small in any case, so moving the unmerged list from the top
of the output to immediately after the list of updated paths would give us
the optimum layout.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The majority of code in core git appears to use a single
space after if/for/while. This is an attempt to bring more
code to this standard. These are entirely cosmetic changes.
Signed-off-by: Brian Gianforcaro <b.gianfo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tentatively add "git stat" as a new command.
This is not "preview of commit with the same arguments"; the path parameters
are not paths to be added to the pristine index (aka "--only" option), but
are taken as pathspecs to limit the output. Later in 1.7.0 release, it will
take over "git status".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The benefit of this one alone is somewhat iffy, but for completeness this
moves the wt_status_colors[] color palette to the wt_status structure to
complete the libification started by the previous commit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Turn four global variables (wt_status_use_color, show_tracked_files,
wt_status_relative_paths, and wt_status_submodule_summary) into fields of
wt_status structure. They can also lose "wt_status_" prefix.
Get rid of "untracked" field that was used only to keep track of otherwise
available information redundantly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a path is unmerged in the index, we used to always say "unmerged" in
the "Changed but not updated" section, even when the path was deleted in
the work tree.
Remove unmerged entries from the "Updated" section, and create a new
section "Unmerged paths". Describe how the different stages conflict
in more detail in this new section.
Note that with the current 3-way merge policy (with or without recursive),
certain combinations of index stages should never happen. For example,
having only stage #2 means that a path that did not exist in the common
ancestor was added by us while the other branch did not do anything to it,
which would have autoresolved to take our addition. The code nevertheless
prepares for the possibility that future merge policies may leave a path
in such a state.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a new infrastructure to find and summarize changes in a single
string list, and rewrite wt_status_print_{updated,changed} functions using
it.
The goal of this change is to give more information on conflicted paths in
the status output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of the users of "read_directory()" actually want a much simpler
interface than the whole complex (but rather powerful) one.
In fact 'git add' had already largely abstracted out the core interface
issues into a private "fill_directory()" function that was largely
applicable almost as-is to a number of callers. Yes, 'git add' wants to
do some extra work of its own, specific to the add semantics, but we can
easily split that out, and use the core as a generic function.
This function does exactly that, and now that much simplified
'fill_directory()' function can be shared with a number of callers,
while also ensuring that the rather more complex calling conventions of
read_directory() are used by fewer call-sites.
This also makes the 'common_prefix()' helper function private to dir.c,
since all callers are now in that file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few remaining ones, but this fixes the trivial ones. It boils
down to two main issues that sparse complains about:
- warning: Using plain integer as NULL pointer
Sparse doesn't like you using '0' instead of 'NULL'. For various good
reasons, not the least of which is just the visual confusion. A NULL
pointer is not an integer, and that whole "0 works as NULL" is a
historical accident and not very pretty.
A few of these remain: zlib is a total mess, and Z_NULL is just a 0.
I didn't touch those.
- warning: symbol 'xyz' was not declared. Should it be static?
Sparse wants to see declarations for any functions you export. A lack
of a declaration tends to mean that you should either add one, or you
should mark the function 'static' to show that it's in file scope.
A few of these remain: I only did the ones that should obviously just
be made static.
That 'wt_status_submodule_summary' one is debatable. It has a few related
flags (like 'wt_status_use_color') which _are_ declared, and are used by
builtin-commit.c. So maybe we'd like to export it at some point, but it's
not declared now, and not used outside of that file, so 'static' it is in
this patch.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Essentially; s/type* /type */ as per the coding guidelines.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mv/parseopt-ls-files:
ls-files: fix broken --no-empty-directory
t3000: use test_cmp instead of diff
parse-opt: migrate builtin-ls-files.
Turn the flags in struct dir_struct into a single variable
Conflicts:
builtin-ls-files.c
t/t3000-ls-files-others.sh
By having flags represented as bits in the new member variable 'flags',
it will be easier to use parse_options when dir_struct is involved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove the literal ANSI escape sequences and replace them by readable
constants.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now for the diff porcelain and the log family, we
call:
init_revisions();
setup_revisions();
DIFF_OPT_SET(ALLOW_TEXTCONV);
However, that means textconv will _always_ be on, instead of
being a default that can be manipulated with
setup_revisions. Instead, we want:
init_revisions();
DIFF_OPT_SET(ALLOW_TEXTCONV);
setup_revisions();
which is what this patch does.
We'll go ahead and move the callsite in wt-status, also;
even though the user can't pass any options here, it is a
cleanup that will help avoid any surprise later if the
setup_revisions line is changed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since we can use the same "diff against empty tree" trick as
we do for the non-initial case, it is trivial to make this
work.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we showed the initial commit, we had no reference to
diff against, so we went through the cache manually.
Nowadays, however, we have a virtual empty tree commit, so
we can simply diff against that to get the same results.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This diff is meant for human consumption, so it makes sense
to apply text conversion here, as we would for the regular
diff porcelain.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git status -v" shows a diff, we did not respect the
user's usual diff preferences at all. Loading just
git_diff_basic_config would give us things like rename
limits and diff drivers. But it makes even more sense to
load git_diff_ui_config, which gives us colorization if the
user has requested it.
Note that we need to take special care to cancel
colorization when writing to the commit template file, as
described in the code comments.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the "git status" display code was originally converted
to C, we copied the code from ls-files to discover whether a
pathname returned by read_directory was an "other", or
untracked, file.
Much later, 5698454e updated the code in ls-files to handle
some new cases caused by gitlinks. This left the code in
wt-status.c broken: it would display submodule directories
as untracked directories. Nobody noticed until now, however,
because unless status.showUntrackedFiles was set to "all",
submodule directories were not actually reported by
read_directory. So the bug was only triggered in the
presence of a submodule _and_ this config option.
This patch pulls the ls-files code into a new function,
cache_name_is_other, and uses it in both places. This should
leave the ls-files functionality the same and fix the bug
in status.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many call sites use strbuf_init(&foo, 0) to initialize local
strbuf variable "foo" which has not been accessed since its
declaration. These can be replaced with a static initialization
using the STRBUF_INIT macro which is just as readable, saves a
function call, and takes up fewer lines.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Reorganize header generation so that all header text related to each
block is in one place.
This adds a function, but makes it easier to see what is generated in
each case. It also allows for easy tweaking of individual headers.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/report-tracking:
branch -r -v: do not spit out garbage
stat_tracking_info(): clear object flags used during counting
git-branch -v: show the remote tracking statistics
git-status: show the remote tracking statistics
Refactor "tracking statistics" code used by "git checkout"
The function "config_error_nonbool", that is defined in "config.c",
is used to report an error when a config key in the config file
should have a corresponding value but it hasn't.
So the parameter to this function should be the key and not the
value, because the value is undefined. And it could crash if the
value is used.
This patches fixes two occurences where the value was passed
instead of the key.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "git status" to show the same remote tracking statistics
"git checkout" gives at the beginning of the output.
Now the necessary low-level machinery is properly factored out, we can do
this quite cleanly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new argument teaches Git to not look for any untracked files,
saving cycles on slow file systems, or large repos.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
This lets you specify how you want untracked files to be listed.
The possible options are:
normal - Show untracked files and directories
all - Show all untracked files
The 'all' mode is used, if the mode is not specified.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
This provides additional warning to users when attempting to
commit to a detached HEAD. It is configurable in color.status.nobranch.
Signed-off-by: Chris Parsons <chris@edendevelopment.co.uk>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git_config() only had a function parameter, but no callback data
parameter. This assumes that all callback functions only modify
global variables.
With this patch, every callback gets a void * parameter, and it is hoped
that this will help the libification effort.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current rename limit default of 100 was arbitrarily
chosen. Testing[1] has shown that on modern hardware, a
limit of 200 adds about a second of computation time, and a
limit of 500 adds about 5 seconds of computation time.
This patch bumps the default limit to 200 for viewing diffs,
and to 500 for performing a merge. The limit for generating
git-status templates is set independently; we bump it up to
200 here, as well, to match the diff limit.
[1]: See <20080211113516.GB6344@coredump.intra.peff.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit teaches 'git commit/status' show a new 'Modified submodules'
section, which is an output from:
git submodule summary --cached --for-status --summary-limit <limit>
just before the 'Untracked files' section.
The <limit> is given by the config variable status.submodulesummary
to limit the submodule summary size. status.submodulesummary is a
bool/int variable with value:
- false or 0 by default to disable the summary, or
- positive number to limit the summary size, or
- true or negative number to unlimit the summary size.
Also mention status.submodulesummary in the documentation.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now we can generate diff to a file descriptor, we do not have to
dup() the stdout around when writing the status output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move quote_path() from wt-status.c to quote.c and rename it as
quote_path_relative(), because it is a better name for a public function.
Also, instead of handcrafted quoting, quote_c_style_counted() is now used,
to make its quoting more consistent with the rest of the system, also
honoring core.quotepath specified in configuration.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
config: add test cases for empty value and no value config variables.
cvsimport: have default merge regex also match beginning of commit message
git clone -s documentation: force a new paragraph for the NOTE
status: suggest "git rm --cached" to unstage for initial commit
Protect get_author_ident_from_commit() from filenames in work tree
upload-pack: Initialize the exec-path.
bisect: use verbatim commit subject in the bisect log
git-cvsimport.txt: fix '-M' description.
Revert "pack-objects: only throw away data during memory pressure"
It makes no sense to suggest "git reset HEAD" since we have
no HEAD commit. This actually used to work but regressed in
f26a0012.
wt_status_print_cached_header was updated to take the whole
wt_status struct rather than just the reference field.
Previously the various code paths were sometimes sending in
s->reference and sometimes sending in NULL, making the
decision on whether this was an initial commit before we
even got to this function. Now we must check the initial
flag here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lt/in-core-index:
lazy index hashing
Create pathname-based hash-table lookup into index
read-cache.c: introduce is_racy_timestamp() helper
read-cache.c: fix a couple more CE_REMOVE conversion
Also use unpack_trees() in do_diff_cache()
Make run_diff_index() use unpack_trees(), not read_tree()
Avoid running lstat(2) on the same cache entry.
index: be careful when handling long names
Make on-disk index representation separate from in-core one
A plain "git commit" would still run lstat() a lot more than necessary,
because wt_status_print() would cause the index to be repeatedly flushed
and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
to be lost, resulting in the files in the index being lstat'ed three
times each.
The reason why wt-status.c ended up invalidating and re-reading the
cache multiple times was that it uses "run_diff_index()", which in turn
uses "read_tree()" to populate the index with *both* the old index and
the tree we want to compare against.
So this patch re-writes run_diff_index() to not use read_tree(), but
instead use "unpack_trees()" to diff the index to a tree. That, in
turn, means that we don't need to modify the index itself, which then
means that we don't need to invalidate it and re-read it!
This, together with the lstat() optimizations, means that "git commit"
on the kernel tree really only needs to lstat() the index entries once.
That noticeably cuts down on the cached timings.
Best time before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.399s
user 0m0.232s
sys 0m0.164s
Best time after:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.254s
user 0m0.140s
sys 0m0.112s
so it's a noticeable improvement in addition to being a nice conceptual
cleanup (it's really not that pretty that "run_diff_index()" dirties the
index!)
Doing an "strace -c" on it also shows that as it cuts the number of
lstat() calls by two thirds, it goes from being lstat()-limited to being
limited by getdents() (which is the readdir system call):
Before:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
60.69 0.000704 0 69230 31 lstat
23.62 0.000274 0 5522 getdents
8.36 0.000097 0 5508 2638 open
2.59 0.000030 0 2869 close
2.50 0.000029 0 274 write
1.47 0.000017 0 2844 fstat
After:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.17 0.000276 0 5522 getdents
26.51 0.000162 0 23112 31 lstat
19.80 0.000121 0 5503 2638 open
4.91 0.000030 0 2864 close
1.48 0.000020 0 274 write
1.34 0.000018 0 2844 fstat
...
It passes the test-suite for me, but this is another of one of those
really core functions, and certainly pretty subtle, so..
NOTE! The Linux lstat() system call is really quite cheap when everything
is cached, so the fact that this is quite noticeable on Linux is likely to
mean that it is *much* more noticeable on other operating systems. I bet
you'll see a much bigger performance improvement from this on Windows in
particular.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When recording a merge that conflicted and ends up in no changes after
manual resolution, commit callchain looked like this:
cmd_commit() ->
prepare_log_message() ->
run_status() ->
wt_status_print()
This invocation of run_status() is asked to find out if there is a
committable change, but it unconditionally gave instructions such as
"use git-add" at the same time. When in merge, we do allow an empty
change to be recorded, so after showing this message the code still went
ahead and made a commit.
This introduces "nowarn" parameter to run_status() to avoid these
useless messages. If we are not allowed to create an empty commit, we
already call run_status() again in the original codepath, and the
message will be shown from that call anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output of git-status was recently changed to output relative
paths. Setting this variable to false restores the old behavior for
any old-timers that prefer it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that we are correctly removing leading prefixes from files in git
status, there is a degenerate case: the directory matching the prefix.
Because we show only the directory name for a directory that contains
only untracked files, it gets collapsed to an empty string.
Example:
$ git init
$ mkdir subdir
$ touch subdir/file
$ git status
...
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# subdir/
So far, so good.
$ cd subdir
$ git status
....
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#
Oops, that's a bit confusing.
This patch prints './' to show that there is some output.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds an option to help scripts find out color settings from
the configuration file.
git config --get-colorbool color.diff
inspects color.diff variable, and exits with status 0 (i.e. success) if
color is to be used. It exits with status 1 otherwise.
If a script wants "true"/"false" answer to the standard output of the
command, it can pass an additional boolean parameter to its command
line, telling if its standard output is a terminal, like this:
git config --get-colorbool color.diff true
When called like this, the command outputs "true" to its standard output
if color is to be used (i.e. "color.diff" says "always", "auto", or
"true"), and "false" otherwise.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* kh/commit: (33 commits)
git-commit --allow-empty
git-commit: Allow to amend a merge commit that does not change the tree
quote_path: fix collapsing of relative paths
Make git status usage say git status instead of git commit
Fix --signoff in builtin-commit differently.
git-commit: clean up die messages
Do not generate full commit log message if it is not going to be used
Remove git-status from list of scripts as it is builtin
Fix off-by-one error when truncating the diff out of the commit message.
builtin-commit.c: export GIT_INDEX_FILE for launch_editor as well.
Add a few more tests for git-commit
builtin-commit: Include the diff in the commit message when verbose.
builtin-commit: fix partial-commit support
Fix add_files_to_cache() to take pathspec, not user specified list of files
Export three helper functions from ls-files
builtin-commit: run commit-msg hook with correct message file
builtin-commit: do not color status output shown in the message template
file_exists(): dangling symlinks do exist
Replace "runstatus" with "status" in the tests
t7501-commit: Add test for git commit <file> with dirty index.
...
The code tries to collapse identical leading components
between the prefix and the path. So if we're in "dir1", the
path "dir1/file" should become just "file". However, we were
ending up with "../dir1/file". The included test expected
the wrong output.
The "len" parameter to quote_path can be negative to mean
"this is a NUL terminated string". Simply count it so that
the loop can rely on it being the length of the path.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
run_diff_index() and the entire diff machinery is hard coded to output
to stdout, so just redirect that and restore it when done.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To show the relative paths, the function formerly called quote_crlf()
(now called quote_path()) takes the prefix as an additional argument.
While at it, the static buffers were replaced by strbufs.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable. The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.
* git-ls-files does not notice any of the "ignore" files by
default, as it predates the standardized set of ignore files.
The calling scripts established the convention to use
.git/info/exclude, .gitignore, and later core.excludesfile.
* git-add and git-status know about it because they call
add_excludes_from_file() directly with their own notion of
which standard set of ignore files to use. This is just a
stupid duplication of code that need to be updated every time
the definition of the standard set of ignore files is
changed.
* git-read-tree takes --exclude-per-directory=<gitignore>,
not because the flexibility was needed. Again, this was
because the option predates the standardization of the ignore
files.
* git-merge-recursive uses hardcoded per-directory .gitignore
and nothing else. git-clean (scripted version) does not
honor core.* because its call to underlying ls-files does not
know about it. git-clean in C (parked in 'pu') doesn't either.
We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way. I am somewhat reluctant to make such a change.
On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands. I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.
This patch is the first step to untangle this mess.
The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We still default to get_index_file(), but this can be overridden
by setting wt_status.index_file after calling wt_status_prepare().
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Still defaults to stdout, but you can now override wt_status.fp after
calling wt_status_prepare().
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.
This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.
The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
