Граф коммитов

25 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano 00d27937bf Merge branch 'jh/status-v2-porcelain'
Enhance "git status --porcelain" output by collecting more data on
the state of the index and the working tree files, which may
further be used to teach git-prompt (in contrib/) to make fewer
calls to git.

* jh/status-v2-porcelain:
  status: unit tests for --porcelain=v2
  test-lib-functions.sh: add lf_to_nul helper
  git-status.txt: describe --porcelain=v2 format
  status: print branch info with --porcelain=v2 --branch
  status: print per-file porcelain v2 status data
  status: collect per-file data for --porcelain=v2
  status: support --porcelain[=<version>]
  status: cleanup API to wt_status_print
  status: rename long-format print routines
2016-09-08 21:49:50 -07:00
Jeff Hostetler c4f596b98e status: support --porcelain[=<version>]
Update --porcelain argument to take optional version parameter
to allow multiple porcelain formats to be supported in the future.

The token "v1" is the default value and indicates the traditional
porcelain format.  (The token "1" is an alias for that.)

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-05 15:46:42 -07:00
Matthieu Moy b0a61ab23c status: suggest 'git merge --abort' when appropriate
We already suggest 'git rebase --abort' during a conflicted rebase.
Similarly, suggest 'git merge --abort' during conflict resolution on
'git merge'.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22 10:20:27 -07:00
Junio C Hamano db43891ce6 Merge branch 'rs/wt-status-detached-branch-fix' into maint
"git status --branch --short" accessed beyond the constant string
"HEAD", which has been corrected.

* rs/wt-status-detached-branch-fix:
  wt-status: use skip_prefix() to get rid of magic string length constants
  wt-status: don't skip a magical number of characters blindly
  wt-status: avoid building bogus branch name with detached HEAD
  wt-status: exit early using goto in wt_shortstatus_print_tracking()
  t7060: add test for status --branch on a detached HEAD
2015-11-05 12:18:15 -08:00
Junio C Hamano a59d1d8035 Merge branch 'rs/wt-status-detached-branch-fix'
"git status --branch --short" accessed beyond the constant string
"HEAD", which has been corrected.

* rs/wt-status-detached-branch-fix:
  wt-status: use skip_prefix() to get rid of magic string length constants
  wt-status: don't skip a magical number of characters blindly
  wt-status: avoid building bogus branch name with detached HEAD
  wt-status: exit early using goto in wt_shortstatus_print_tracking()
  t7060: add test for status --branch on a detached HEAD
2015-11-03 15:13:08 -08:00
René Scharfe baf0a3e47d wt-status: avoid building bogus branch name with detached HEAD
If we're on a detached HEAD then wt_shortstatus_print_tracking() takes
the string "HEAD (no branch)", translates it, skips the first eleven
characters and passes the result to branch_get(), which returns a bogus
result and accesses memory out of bounds in order to produce it.
Somehow stat_tracking_info(), which is passed that result, does the
right thing anyway, i.e. it finds that there is no base.

Avoid the bogus results and memory accesses by checking for HEAD first
and exiting early in that case.  This fixes t7060 with --valgrind.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01 09:58:20 -08:00
René Scharfe 7ca8c18950 t7060: add test for status --branch on a detached HEAD
This test fails when run under Valgrind because branch_get() gets passed
a bogus branch name pointer:

==62831== Invalid read of size 1
==62831==    at 0x4F76AE: branch_get (remote.c:1650)
==62831==    by 0x53499E: wt_shortstatus_print_tracking (wt-status.c:1654)
==62831==    by 0x53499E: wt_shortstatus_print (wt-status.c:1706)
==62831==    by 0x428D29: cmd_status (commit.c:1384)
==62831==    by 0x405D6D: run_builtin (git.c:350)
==62831==    by 0x405D6D: handle_builtin (git.c:536)
==62831==    by 0x404F10: run_argv (git.c:582)
==62831==    by 0x404F10: main (git.c:690)
==62831==  Address 0x5e89b0b is 6 bytes after a block of size 5 alloc'd
==62831==    at 0x4C28C4F: malloc (vg_replace_malloc.c:299)
==62831==    by 0x59579E9: strdup (strdup.c:42)
==62831==    by 0x52E108: xstrdup (wrapper.c:43)
==62831==    by 0x5322A6: wt_status_prepare (wt-status.c:130)
==62831==    by 0x4276E0: status_init_config (commit.c:184)
==62831==    by 0x428BB8: cmd_status (commit.c:1350)
==62831==    by 0x405D6D: run_builtin (git.c:350)
==62831==    by 0x405D6D: handle_builtin (git.c:536)
==62831==    by 0x404F10: run_argv (git.c:582)
==62831==    by 0x404F10: main (git.c:690)

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-01 09:58:20 -08:00
Junio C Hamano 971f9ea543 Merge branch 'mp/t7060-diff-index-test'
Fix an old test that was doing the same thing as another one.

* mp/t7060-diff-index-test:
  t7060: actually test "git diff-index --cached -M"
2015-09-14 11:46:31 -07:00
Matthieu Prat b894d3e788 t7060: actually test "git diff-index --cached -M"
A test was designed for "git diff-index --cached -M" but the command is
run without the "-M" option (which makes the test essentially identical
to its preceding counterpart).

Signed-off-by: Matthieu Prat <matthieuprat@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02 12:23:30 -07:00
Junio C Hamano c7cb333f60 wt-status: lift the artificual "at least 20 columns" floor
When we show unmerged paths, we had an artificial 20 columns floor
for the width of labels (e.g. "both deleted:") shown next to the
pathnames.  Depending on the locale, this may result in a label that
is too wide when all the label strings are way shorter than 20
columns, or no-op when a label string is longer than 20 columns.

Just drop the artificial floor.  The screen real estate is better
utilized this way when all the strings are shorter.

Adjust the tests to this change.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-12 14:08:05 -07:00
Matthieu Moy 1c7969c933 tests: don't set status.displayCommentPrefix file-wide
The previous commit set status.displayCommentPrefix file-wide in
t7060-wtstatus.sh, t7508-status.sh and t/t7512-status-help.sh to make the
patch small. However, now that status.displayCommentPrefix is not the
default, it is better to disable it in tests so that the most common
situation is also the most tested.

While we're there, move the "cat > expect << EOF" blocks inside the
tests.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06 13:33:18 -07:00
Matthieu Moy 2556b9962e status: disable display of '#' comment prefix by default
Historically, "git status" needed to prefix each output line with '#' so
that the output could be added as comment to the commit message. This
prefix comment has no real purpose when "git status" is ran from the
command-line, and this may distract users from the real content.

Disable this prefix comment by default, and make it re-activable for
users needing backward compatibility with status.displayCommentPrefix.

Obviously, "git commit" ignores status.displayCommentPrefix and keeps the
comment unconditionnaly when writing to COMMIT_EDITMSG (but not when
writing to stdout for an error message or with --dry-run).

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06 13:33:18 -07:00
Nguyễn Thái Ngọc Duy 6a38ef2ced status: advise to consider use of -u when read_directory takes too long
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>
2013-03-16 21:44:58 -07:00
Lucien Kong 96b0ec1a4c status: don't suggest "git rm" or "git add" if not appropriate
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>
2012-06-14 10:15:19 -07:00
Lucien Kong 83c750acde wt-status.*: better advices for git status added
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>
2012-06-14 10:15:19 -07:00
Junio C Hamano a75c3523d3 Merge branch 'ab/i18n-fixup'
* ab/i18n-fixup: (24 commits)
  i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811
  i18n: use test_i18n{grep,cmp} in t7508
  i18n: use test_i18ngrep in t7506
  i18n: use test_i18ngrep and test_i18ncmp in t7502
  i18n: use test_i18ngrep in t7501
  i18n: use test_i18ncmp in t7500
  i18n: use test_i18ngrep in t7201
  i18n: use test_i18ncmp and test_i18ngrep in t7102 and t7110
  i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060
  i18n: use test_i18ncmp and test_i18ngrep in t3700, t4001 and t4014
  i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507
  i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200
  i18n: use test_i18ngrep in lib-httpd and t2019
  i18n: do not overuse C_LOCALE_OUTPUT (grep)
  i18n: use test_i18ncmp in t1200 and t2200
  i18n: .git file is not a human readable message (t5601)
  i18n: do not overuse C_LOCALE_OUTPUT
  i18n: mark init-db messages for translation
  i18n: mark checkout plural warning for translation
  i18n: mark checkout --detach messages for translation
  ...
2011-05-02 15:58:40 -07:00
Junio C Hamano 2db8926236 Merge branch 'mz/maint-rename-unmerged'
* mz/maint-rename-unmerged:
  diffcore-rename: don't consider unmerged path as source
2011-05-02 15:58:27 -07:00
Junio C Hamano b3e1900a74 i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13 15:52:47 -07:00
Martin von Zweigbergk d7c9bf2235 diffcore-rename: don't consider unmerged path as source
Since e9c8409 (diff-index --cached --raw: show tree entry on the LHS for
unmerged entries., 2007-01-05), an unmerged entry should be detected by
using DIFF_PAIR_UNMERGED(p), not by noticing both one and two sides of
the filepair records mode=0 entries. However, it forgot to update some
parts of the rename detection logic.

This only makes difference in the "diff --cached" codepath where an
unmerged filepair carries information on the entries that came from the
tree.  It probably hasn't been noticed for a long time because nobody
would run "diff -M" during a conflict resolution, but "git status" uses
rename detection when it internally runs "diff-index" and "diff-files"
and gives nonsense results.

In an unmerged pair, "one" side can have a valid filespec to record the
tree entry (e.g. what's in HEAD) when running "diff --cached". This can
be used as a rename source to other paths in the index that are not
unmerged. The path that is unmerged by definition does not have the
final content yet (i.e. "two" side cannot have a valid filespec), so it
can never be a rename destination.

Use the DIFF_PAIR_UNMERGED() to detect unmerged filepair correctly, and
allow the valid "one" side of an unmerged filepair to be considered a
potential rename source, but never to be considered a rename destination.

Commit message and first two test cases by Junio, the rest by Martin.

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-23 22:44:22 -07:00
Ævar Arnfjörð Bjarmason 355ec7a130 i18n: git-status basic messages
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>
2011-03-09 23:52:56 -08:00
Junio C Hamano 3c58845365 status/commit: do not suggest "reset HEAD <path>" while merging
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>
2009-12-12 01:22:10 -08:00
Junio C Hamano dd20f8af1a commit/status: "git add <path>" is not necessarily how to resolve
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>
2009-12-12 01:21:38 -08:00
Junio C Hamano 9e4b7ab652 git status: not "commit --dry-run" anymore
This removes tentative "git stat" and make it take over "git status".

There are some tests that expect "git status" to exit with non-zero status
when there is something staged.  Some tests expect "git status path..." to
show the status for a partial commit.

For these, replace "git status" with "git commit --dry-run".  For the
ones that do not attempt a dry-run of a partial commit that check the
output from the command, check the output from "git status" as well, as
they should be identical.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-22 12:18:00 -07:00
Junio C Hamano 4d4d5726ae status: show worktree status of conflicted paths separately
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>
2009-08-06 21:16:01 -07:00
Junio C Hamano 29796c6ccf diff-index: report unmerged new entries
Since an earlier change to diff-index by d1f2d7e (Make run_diff_index()
use unpack_trees(), not read_tree(), 2008-01-19), we stopped reporting an
unmerged path that does not exist in the tree, but we should.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05 02:21:11 -07:00