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>
