summaryrefslogtreecommitdiff
path: root/t/t7512-status-help.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-02-16rebase: rename the two primary rebase backendsLibravatar Elijah Newren1-6/+6
Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase tests: mark tests specific to the am-backend with --amLibravatar Elijah Newren1-6/+6
We have many rebase tests in the testsuite, and often the same test is repeated multiple times just testing different backends. For those tests that were specifically trying to test the am backend, add the --am flag. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27status: mention --skip for revert and cherry-pickLibravatar Denton Liu1-0/+6
When reverting or cherry-picking, one of the options we can pass the sequencer is `--skip`. However, unlike rebasing, `--skip` is not mentioned as a possible option in the status message. Mention it so that users are more aware of their options. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-19Merge branch 'jl/status-reduce-vertical-blank'Libravatar Junio C Hamano1-14/+0
Extra blank lines in "git status" output have been reduced. * jl/status-reduce-vertical-blank: status: remove the empty line after hints
2019-07-19Merge branch 'pw/status-with-corrupt-sequencer-state'Libravatar Junio C Hamano1-0/+16
The code to read state files used by the sequencer machinery for "git status" has been made more robust against a corrupt or stale state files. * pw/status-with-corrupt-sequencer-state: status: do not report errors in sequencer/todo sequencer: factor out todo command name parsing sequencer: always allow tab after command name
2019-07-09Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-10/+10
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-06-27status: do not report errors in sequencer/todoLibravatar Phillip Wood1-0/+16
commit 4a72486de9 ("fix cherry-pick/revert status after commit", 2019-04-16) used parse_insn_line() to parse the first line of the todo list to check if it was a pick or revert. However if the todo list is left over from an old cherry-pick or revert and references a commit that no longer exists then parse_insn_line() prints an error message which is confusing for users [1]. Instead parse just the command name so that the user is alerted to the presence of stale sequencer state by status reporting that a cherry-pick or revert is in progress. Note that we should not be leaving stale sequencer state lying around (or at least not as often) after commit b07d9bfd17 ("commit/reset: try to clean up sequencer state", 2019-04-16). However the user may still have stale state that predates that commit. Also avoid printing an error message if for some reason the user has a file called `sequencer` in $GIT_DIR. [1] https://public-inbox.org/git/3bc58c33-4268-4e7c-bf1a-fe349b3cb037@www.fastmail.com/ Reported-by: Espen Antonsen <espen@inspired.no> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-21status: remove the empty line after hintsLibravatar John Lin1-14/+0
Before this patch, there is inconsistency between the status messages with hints and the ones without hints: there is an empty line between the title and the file list if hints are presented, but there isn't one if there are no hints. This patch remove the inconsistency by removing the empty lines even if hints are presented. Signed-off-by: John Lin <johnlinp@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07doc: promote "git restore"Libravatar Nguyễn Thái Ngọc Duy1-10/+10
The new command "git restore" (together with "git switch") are added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguous context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands. One nice thing about git-restore is the ability to restore "everything", so it can be used in "git status" advice instead of both "git checkout" and "git reset". The three commands suggested by "git status" are add, rm and restore. "git checkout" is also removed from "git help" (i.e. it's no longer considered a commonly used command) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-17fix cherry-pick/revert status after commitLibravatar Phillip Wood1-0/+36
If the user commits a conflict resolution using `git commit` in the middle of a sequence of cherry-picks/reverts then `git status` missed the fact that a cherry-pick/revert is still in progress. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-26status: be prepared for not-yet-started interactive rebaseLibravatar Johannes Schindelin1-0/+19
Some developers might want to call `git status` in a working directory where they just started an interactive rebase, but the edit script is still opened in the editor. Let's show a meaningful message in such cases. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22status: suggest 'git merge --abort' when appropriateLibravatar Matthieu Moy1-0/+1
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>
2015-07-06status: add new tests for status during rebase -iLibravatar Guillaume Pagès1-0/+87
Expand test coverage with one or more than two commands done and with zero, one or more than two commands remaining. Signed-off-by: Guillaume Pagès <guillaume.pages@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06status: give more information during rebase -iLibravatar Guillaume Pagès1-0/+111
git status gives more information during rebase -i, about the list of command that are done during the rebase. It displays the two last commands executed and the two next lines to be executed. It also gives hints to find the whole files in .git directory. Signed-off-by: Guillaume Pagès <guillaume.pages@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30status: differentiate interactive from non-interactive rebasesLibravatar Guillaume Pagès1-14/+14
Signed-off-by: Guillaume Pagès <guillaume.pages@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-12wt-status: lift the artificual "at least 20 columns" floorLibravatar Junio C Hamano1-6/+6
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>
2013-10-11status: show commit sha1 in "You are currently cherry-picking" messageLibravatar Ralf Thielow1-4/+6
Especially helpful when cherry-picking multiple commits. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-10-11status test: add missing && to <<EOF blocksLibravatar Jonathan Nieder1-5/+5
When a test forgets to include && after each command, it is possible for an early command to succeed but the test to fail, which can hide bugs. Checked using the following patch to the test harness: --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -425,7 +425,17 @@ test_eval_ () { eval </dev/null >&3 2>&4 "$*" } +check_command_chaining_ () { + eval >&3 2>&4 "(exit 189) && $*" + eval_chain_ret=$? + if test "$eval_chain_ret" != 189 + then + error 'bug in test script: missing "&&" in test commands' + fi +} + test_run_ () { + check_command_chaining_ "$1" test_cleanup=: expecting_failure=$2 setup_malloc_check Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-06tests: don't set status.displayCommentPrefix file-wideLibravatar Matthieu Moy1-304/+300
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-06status: disable display of '#' comment prefix by defaultLibravatar Matthieu Moy1-0/+4
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-07-11Merge branch 'rr/rebase-checkout-reflog'Libravatar Junio C Hamano1-21/+26
Invocations of "git checkout" used internally by "git rebase" were counted as "checkout", and affected later "git checkout -" to the the user to an unexpected place. * rr/rebase-checkout-reflog: checkout: respect GIT_REFLOG_ACTION status: do not depend on rebase reflog messages t/t2021-checkout-last: "checkout -" should work after a rebase finishes wt-status: remove unused field in grab_1st_switch_cbdata t7512: test "detached from" as well
2013-06-27am: replace uses of --resolved with --continueLibravatar Kevin Bracey1-2/+2
git am was previously modified to provide --continue for consistency with rebase, merge etc, and the documentation changed to showing --continue as the primary form. Complete the work by replacing remaining uses of --resolved by --continue, most notably in suggested command reminders. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17wt-status: give better advice when cherry-pick is in progressLibravatar Ralf Thielow1-2/+4
When cherry-pick is in progress, 'git status' gives the advice to run "git commit" to finish the cherry-pick. However, this won't continue the sequencer, when picking a range of commits. Advise users to run "git cherry-pick --continue/--abort"; they work when picking a single commit as well. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17status: do not depend on rebase reflog messagesLibravatar Ramkumar Ramachandra1-20/+17
b397ea4 (status: show more info than "currently not on any branch", 2013-03-13) attempted to make the output of 'git status' richer in the case of a detached HEAD. Before this patch, with a detached HEAD, we saw: $ git status # Not currently on any branch. But after the patch, we see: $ git checkout v1.8.2 $ git status # HEAD detached at v1.8.2. It works by digging the reflog for the most recent message of the form "checkout: moving from xxxx to yyyy". It then asserts that HEAD and "yyyy" are the same, and displays this message. When they aren't equal, it displays: $ git status # HEAD detached from fe11db. so that the user can see where the HEAD was first detached. In case of a rebase [-i] operation in progress, this message depends on the implementation of rebase writing "checkout: " messages to the reflog, but that is an implementation detail of "rebase". To remove this dependency so that rebase can be updated to write better reflog messages, replace this "HEAD detached from" message with: # rebase in progress; onto $ONTO Changes to the commit object name in the expected output for some of the tests shows that what the test expected "status" to show during "rebase -i" was not consistent with the output during a vanilla "rebase", which showed on top of what commit the series is being replayed. Now we consistently expect something meaningful to the end user. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17t7512: test "detached from" as wellLibravatar Junio C Hamano1-1/+9
b397ea4863a1 (status: show more info than "currently not on any branch", 2013-03-13) wanted to make sure that after a checkout to detach HEAD, the user can see where the HEAD was originally detached from. The last test added by that commit to t7512 shows one example, immediately after HEAD is detached. Enhance that test to show "detached HEAD from" form that should be shown when the user further resetted to another commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02status: show commit sha1 in "You are currently reverting" messageLibravatar Matthieu Moy1-3/+4
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02status: show 'revert' state and status hintLibravatar Matthieu Moy1-0/+57
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>
2013-04-01Merge branch 'nd/branch-show-rebase-bisect-state'Libravatar Junio C Hamano1-20/+34
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()
2013-03-23status, branch: fix the misleading "bisecting" messageLibravatar Nguyễn Thái Ngọc Duy1-1/+1
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>
2013-03-21Merge branch 'tb/document-status-u-tradeoff'Libravatar Junio C Hamano1-0/+1
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
2013-03-16status: show more info than "currently not on any branch"Libravatar Nguyễn Thái Ngọc Duy1-19/+33
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>
2013-03-16status: advise to consider use of -u when read_directory takes too longLibravatar Nguyễn Thái Ngọc Duy1-0/+1
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-02-25Sync with 'maint'Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-25Documentation: "advice" is uncountableLibravatar Greg Price1-1/+1
"Advice" is a mass noun, not a count noun; it's not ordinarily pluralized. Signed-off-by: Greg Price <price@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-05status: show the branch name if possible in in-progress infoLibravatar Nguyễn Thái Ngọc Duy1-35/+52
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>
2012-06-14status: better advices when splitting a commit (during rebase -i)Libravatar Lucien Kong1-0/+277
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>
2012-06-14status: don't suggest "git rm" or "git add" if not appropriateLibravatar Lucien Kong1-4/+4
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-14t7512-status-help.sh: better advices for git statusLibravatar Lucien Kong1-0/+372
The following tests include several cases in which the user needs to run 'git status' to know his current situation, whether there're conflicts or he's in rebase/bisect/am/cherry-pick progress. One of the test is about the set of the advice.statushints config key to 'false' in .git/config. 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>