summaryrefslogtreecommitdiff
path: root/advice.c
AgeCommit message (Collapse)AuthorFilesLines
2019-07-19Merge branch 'ra/cherry-pick-revert-skip'Libravatar Junio C Hamano1-0/+2
"git cherry-pick/revert" learned a new "--skip" action. * ra/cherry-pick-revert-skip: cherry-pick/revert: advise using --skip cherry-pick/revert: add --skip option sequencer: use argv_array in reset_merge sequencer: rename reset_for_rollback to reset_merge sequencer: add advice for revert
2019-07-09Merge branch 'ds/fetch-disable-force-notice'Libravatar Junio C Hamano1-0/+2
"git fetch" and "git pull" reports when a fetch results in non-fast-forward updates to let the user notice unusual situation. The commands learned "--no-shown-forced-updates" option to disable this safety feature. * ds/fetch-disable-force-notice: pull: add --[no-]show-forced-updates passthrough fetch: warn about forced updates in branch listing fetch: add --[no-]show-forced-updates argument
2019-07-09Merge branch 'jh/status-aheadbehind'Libravatar Junio C Hamano1-0/+2
"git status" can be told a non-standard default value for the "--[no-]ahead-behind" option with a new configuration variable status.aheadBehind. * jh/status-aheadbehind: status: ignore status.aheadbehind in porcelain formats status: warn when a/b calculation takes too long status: add status.aheadbehind setting
2019-07-09Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-4/+13
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-07-02sequencer: add advice for revertLibravatar Rohit Ashiwal1-0/+2
In the case of merge conflicts, while performing a revert, we are currently advised to use `git cherry-pick --<sequencer-options>`. Introduce a separate advice message for `git revert`. Also change the signature of `create_seq_dir` to handle which advice to display selectively. Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-21fetch: warn about forced updates in branch listingLibravatar Derrick Stolee1-0/+2
The --[no-]show-forced-updates option in 'git fetch' can be confusing for some users, especially if it is enabled via config setting and not by argument. Add advice to warn the user that the (forced update) messages were not listed. Additionally, warn users when the forced update check takes longer than ten seconds, and recommend that they disable the check. These messages can be disabled by the advice.fetchShowForcedUpdates config setting. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-21status: warn when a/b calculation takes too longLibravatar Jeff Hostetler1-0/+2
The ahead/behind calculation in 'git status' can be slow in some cases. Users may not realize that there are ways to avoid this computation, especially if they are not using the information. Add a warning that appears if this calculation takes more than two seconds. The warning can be disabled through the new config setting advice.statusAheadBehind. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12tag: advise on nested tagsLibravatar Denton Liu1-0/+2
Robert Dailey reported confusion on the mailing list about a nested tag which was most likely created by mistake. Jeff King noted that this isn't a very common case and creating a tag-to-a-tag can be a user-error. Suggest that it may be a mistake with an advice message when creating such a tag. Those who do want to create a tag that point at another tag regularly can turn it off with the usual advice mechanism. Reported-by: Robert Dailey <rcdailey.lists@gmail.com> Helped-by: Jeff King <peff@peff.net> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> [jc: fixed test style and tweaked the log message] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02doc: promote "git switch"Libravatar Nguyễn Thái Ngọc Duy1-6/+6
The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands... The "Checking out files" progress line in unpack-trees.c is also updated to "Updating files" to be neutral to both git-checkout and git-switch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02checkout: advice how to get out of detached HEAD modeLibravatar Nguyễn Thái Ngọc Duy1-4/+13
Detached HEAD mode is considered dangerous and confusing for newcomers and we print a big block of warning how to move forward. But we should also suggest the user the way to get out of it if they get into detached HEAD by mistake. While at there, I also suggest how to turn the advice off. This is another thing I find annoying with advices and should be dealt with in a more generic way. But that may require some refactoring in advice.c first. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14push: add an advice on unqualified <dst> pushLibravatar Ævar Arnfjörð Bjarmason1-0/+2
Add an advice to the recently improved error message added in f8aae12034 ("push: allow unqualified dest refspecs to DWIM", 2008-04-23). Now with advice.pushUnqualifiedRefName=true (on by default) we show a hint about how to proceed: $ ./git-push avar v2.19.0^{commit}:newbranch -n error: The destination you provided is not a full refname (i.e., starting with "refs/"). We tried to guess what you meant by: - Looking for a ref that matches 'newbranch' on the remote side. - Checking if the <src> being pushed ('v2.19.0^{commit}') is a ref in "refs/{heads,tags}/". If so we add a corresponding refs/{heads,tags}/ prefix on the remote side. Neither worked, so we gave up. You must fully qualify the ref. hint: The <src> part of the refspec is a commit object. hint: Did you mean to create a new branch by pushing to hint: 'v2.19.0^{commit}:refs/heads/newbranch'? error: failed to push some refs to 'git@github.com:avar/git.git' When trying to push a tag, tree or a blob we suggest that perhaps the user meant to push them to refs/tags/ instead. The if/else duplication for all of OBJ_{COMMIT,TAG,TREE,BLOB} is unfortunate, but is required to correctly mark the messages for translation. See the discussion in <87r2gxebsi.fsf@evledraar.gmail.com> about that. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24reset: warn when refresh_index() takes more than 2 secondsLibravatar Ben Peart1-0/+2
refresh_index() is done after a reset command as an optimization. Because it can be an expensive call, warn the user if it takes more than 2 seconds and tell them how to avoid it using the --quiet command line option or reset.quiet config setting. Signed-off-by: Ben Peart <benpeart@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-02Merge branch 'ab/checkout-default-remote'Libravatar Junio C Hamano1-0/+2
"git checkout" and "git worktree add" learned to honor checkout.defaultRemote when auto-vivifying a local branch out of a remote tracking branch in a repository with multiple remotes that have tracking branches that share the same names. * ab/checkout-default-remote: checkout & worktree: introduce checkout.defaultRemote checkout: add advice for ambiguous "checkout <branch>" builtin/checkout.c: use "ret" variable for return checkout: pass the "num_matches" up to callers checkout.c: change "unique" member to "num_matches" checkout.c: introduce an *_INIT macro checkout.h: wrap the arguments to unique_tracking_name() checkout tests: index should be clean after dwim checkout
2018-06-11checkout: add advice for ambiguous "checkout <branch>"Libravatar Ævar Arnfjörð Bjarmason1-0/+2
As the "checkout" documentation describes: If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to [...] <remote>/<branch. This is a really useful feature. The problem is that when you add another remote (e.g. a fork), git won't find a unique branch name anymore, and will instead print this unhelpful message: $ git checkout master error: pathspec 'master' did not match any file(s) known to git Now it will, on my git.git checkout, print: $ ./git --exec-path=$PWD checkout master error: pathspec 'master' did not match any file(s) known to git. hint: 'master' matched more than one remote tracking branch. hint: We found 26 remotes with a reference that matched. So we fell back hint: on trying to resolve the argument as a path, but failed there too! hint: hint: If you meant to check out a remote tracking branch on, e.g. 'origin', hint: you can do so by fully qualifying the name with the --track option: hint: hint: git checkout --track origin/<name> Note that the "error: pathspec[...]" message is still printed. This is because whatever else checkout may have tried earlier, its final fallback is to try to resolve the argument as a path. E.g. in this case: $ ./git --exec-path=$PWD checkout master pu error: pathspec 'master' did not match any file(s) known to git. error: pathspec 'pu' did not match any file(s) known to git. There we don't print the "hint:" implicitly due to earlier logic around the DWIM fallback. That fallback is only used if it looks like we have one argument that might be a branch. I can't think of an intrinsic reason for why we couldn't in some future change skip printing the "error: pathspec[...]" error. However, to do so we'd need to pass something down to checkout_paths() to make it suppress printing an error on its own, and for us to be confident that we're not silencing cases where those errors are meaningful. I don't think that's worth it since determining whether that's the case could easily change due to future changes in the checkout logic. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-29am: move advice.amWorkDir parsing back to advice.cLibravatar Nguyễn Thái Ngọc Duy1-0/+2
The only benefit from this move (apart from cleaner code) is that advice.amWorkDir should now show up in `git help --config`. There should be no regression since advice config is always read by the git_default_config(). While at there, use advise() like other code. We now get "hint: " prefix and the output is stderr instead of stdout (which is also the reason for the test update because stderr is checked in a following test and the extra advice can fail it). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-29advice: keep config name in camelCase in advice_config[]Libravatar Nguyễn Thái Ngọc Duy1-21/+21
For parsing, we don't really need this because the main config parser will lowercase everything so we can do exact matching. But this array now is also used for printing in `git help --config`. Keep camelCase so we have a nice printout. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-29help: add --config to list all available configLibravatar Nguyễn Thái Ngọc Duy1-0/+9
Sometimes it helps to list all available config vars so the user can search for something they want. The config man page can also be used but it's harder to search if you want to focus on the variable name, for example. This is not the best way to collect the available config since it's not precise. Ideally we should have a centralized list of config in C code (pretty much like 'struct option'), but that's a lot more work. This will do for now. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-23Merge branch 'js/deprecate-grafts'Libravatar Junio C Hamano1-0/+2
The functionality of "$GIT_DIR/info/grafts" has been superseded by the "refs/replace/" mechanism for some time now, but the internal code had support for it in many places, which has been cleaned up in order to drop support of the "grafts" mechanism. * js/deprecate-grafts: Remove obsolete script to convert grafts to replace refs technical/shallow: describe why shallow cannot use replace refs technical/shallow: stop referring to grafts filter-branch: stop suggesting to use grafts Deprecate support for .git/info/grafts Add a test for `git replace --convert-graft-file` replace: introduce --convert-graft-file replace: prepare create_graft() for converting graft files wholesale replace: "libify" create_graft() and callees replace: avoid using die() to indicate a bug commit: Let the callback of for_each_mergetag return on error argv_array: offer to split a string by whitespace
2018-04-30Deprecate support for .git/info/graftsLibravatar Johannes Schindelin1-0/+2
The grafts feature was a convenient way to "stitch together" ancient history to the fresh start of linux.git. Its implementation is, however, not up to Git's standards, as there are too many ways where it can lead to surprising and unwelcome behavior. For example, when pushing from a repository with active grafts, it is possible to miss commits that have been "grafted out", resulting in a broken state on the other side. Also, the grafts feature is limited to "rewriting" commits' list of parents, it cannot replace anything else. The much younger feature implemented as `git replace` set out to remedy those limitations and dangerous bugs. Seeing as `git replace` is pretty mature by now (since 4228e8bc98 (replace: add --graft option, 2014-07-19) it can perform the graft file's duties), it is time to deprecate support for the graft file, and to retire it eventually. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-24push: colorize errorsLibravatar Ryan Dammrose1-2/+47
This is an attempt to resolve an issue I experience with people that are new to Git -- especially colleagues in a team setting -- where they miss that their push to a remote location failed because the failure and success both return a block of white text. An example is if I push something to a remote repository and then a colleague attempts to push to the same remote repository and the push fails because it requires them to pull first, but they don't notice because a success and failure both return a block of white text. They then continue about their business, thinking it has been successfully pushed. This patch colorizes the errors and hints (in red and yellow, respectively) so whenever there is a failure when pushing to a remote repository that fails, it is more noticeable. [jes: fixed a couple bugs, added the color.{advice,push,transport} settings, refactored to use want_color_stderr().] Signed-off-by: Ryan Dammrose ryandammrose@gmail.com Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-19Merge branch 'ls/editor-waiting-message'Libravatar Junio C Hamano1-0/+2
Git shows a message to tell the user that it is waiting for the user to finish editing when spawning an editor, in case the editor opens to a hidden window or somewhere obscure and the user gets lost. * ls/editor-waiting-message: launch_editor(): indicate that Git waits for user input refactor "dumb" terminal determination
2017-12-07launch_editor(): indicate that Git waits for user inputLibravatar Lars Schneider1-0/+2
When a graphical GIT_EDITOR is spawned by a Git command that opens and waits for user input (e.g. "git rebase -i"), then the editor window might be obscured by other windows. The user might be left staring at the original Git terminal window without even realizing that s/he needs to interact with another window before Git can proceed. To this user Git appears hanging. Print a message that Git is waiting for editor input in the original terminal and get rid of it when the editor returns, if the terminal supports erasing the last line. Also, make sure that our message is terminated with a whitespace so that any message the editor may show upon starting up will be kept separate from our message. Power users might not want to see this message or their editor might already print such a message (e.g. emacsclient). Allow these users to suppress the message by disabling the "advice.waitingForEditor" config. The standard advise() function is not used here as it would always add a newline which would make deleting the message harder. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-10run-command: add hint when a hook is ignoredLibravatar Damien Marié1-0/+2
When an hook is present but the file is not set as executable then git will ignore the hook. For now this is silent which can be confusing. This commit adds this warning to improve the situation: hint: The 'pre-commit' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false` To allow the old use-case of enabling/disabling hooks via the executable flag a new setting is introduced: advice.ignoredHook. Signed-off-by: Damien Marié <damien@dam.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-24Merge branch 'jk/warn-add-gitlink'Libravatar Junio C Hamano1-0/+2
Using "git add d/i/r" when d/i/r is the top of the working tree of a separate repository would create a gitlink in the index, which would appear as a not-quite-initialized submodule to others. We learned to give warnings when this happens. * jk/warn-add-gitlink: t: move "git add submodule" into test blocks add: warn when adding an embedded repository
2017-06-15config: don't include config.h by defaultLibravatar Brandon Williams1-0/+1
Stop including config.h by default in cache.h. Instead only include config.h in those files which require use of the config system. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15add: warn when adding an embedded repositoryLibravatar Jeff King1-0/+2
It's an easy mistake to add a repository inside another repository, like: git clone $url git add . The resulting entry is a gitlink, but there's no matching .gitmodules entry. Trying to use "submodule init" (or clone with --recursive) doesn't do anything useful. Prior to v2.13, such an entry caused git-submodule to barf entirely. In v2.13, the entry is considered "inactive" and quietly ignored. Either way, no clone of your repository can do anything useful with the gitlink without the user manually adding the submodule config. In most cases, the user probably meant to either add a real submodule, or they forgot to put the embedded repository in their .gitignore file. Let's issue a warning when we see this case. There are a few things to note: - the warning will go in the git-add porcelain; anybody wanting to do low-level manipulation of the index is welcome to create whatever funny states they want. - we detect the case by looking for a newly added gitlink; updates via "git add submodule" are perfectly reasonable, and this avoids us having to investigate .gitmodules entirely - there's a command-line option to suppress the warning. This is needed for git-submodule itself (which adds the entry before adding any submodule config), but also provides a mechanism for other scripts doing submodule-like things. We could make this a hard error instead of a warning. However, we do add lots of sub-repos in our test suite. It's not _wrong_ to do so. It just creates a state where users may be surprised. Pointing them in the right direction with a gentle hint is probably the best option. There is a config knob that can disable the (long) hint. But I intentionally omitted a config knob to disable the warning entirely. Whether the warning is sensible or not is generally about context, not about the user's preferences. If there's a tool or workflow that adds gitlinks without matching .gitmodules, it should probably be taught about the new command-line option, rather than blanket-disabling the warning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: advice: internationalize message for conflictsLibravatar Vasco Almeida1-2/+15
Mark message for translation telling the user she has conflicts to resolve. Expose each particular use case, in order to enable translating entire sentences which would facilitate translating into other languages. Change "Pull" to lowercase to match other instances. Update test t5520-pull.sh, that relied on the old error message, to use the new one. Although we loose in source code conciseness, we would gain better translations because translators can 1) translate the entire sentence, including those terms concerning Git (committing, merging, etc) 2) have leeway to adapt to their languages. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: advice: mark string about detached head for translationLibravatar Vasco Almeida1-3/+3
Mark string with advice seen by the user when in detached head. Update test t7201-co.sh to pass under GETTEXT_POISON build. Pretend success if the number of lines of "git checkout renamer^" output is not greater than 1 and test are running under GETTEXT_POISON. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-02merge: grammofix in please-commit-before-merge messageLibravatar Alex Henrie1-1/+1
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-18pull: check if in unresolved merge stateLibravatar Paul Tan1-0/+8
Since d38a30d (Be more user-friendly when refusing to do something because of conflict., 2010-01-12), git-pull will error out with user-friendly advices if the user is in the middle of a merge or has unmerged files. Re-implement this behavior. While the "has unmerged files" case can be handled by die_resolve_conflict(), we introduce a new function die_conclude_merge() for printing a different error message for when there are no unmerged files but the merge has not been finished. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-14standardize usage info string formatLibravatar Alex Henrie1-1/+1
This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-28merge, pull: stop advising 'commit -a' in case of conflictLibravatar Matthieu Moy1-2/+1
'git commit -a' is rarely a good way to mark conflicts as resolved: the user anyway has to go manually through the list of conflicts to do the actual resolution, and it is usually better to use "git add" on each files after doing the resolution. On the other hand, using 'git commit -a' is potentially dangerous, as it makes it very easy to mistakenly commit conflict markers without noticing, and even worse, the user may have started a merge while having local changes that do not overlap with it in the working tree. While we're there, synchronize the 'git pull' and 'git merge' messages: the first was ending with '... and make a commit.', but not the latter. Eventually, git should detect that conflicts have been resolved in the working tree and tailor these messages further. Not only "use git commit -a" could be resurected, but "Fix them up in the work tree" should be dropped when it happens. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-20refactor skip_prefix to return a booleanLibravatar Jeff King1-1/+4
The skip_prefix() function returns a pointer to the content past the prefix, or NULL if the prefix was not found. While this is nice and simple, in practice it makes it hard to use for two reasons: 1. When you want to conditionally skip or keep the string as-is, you have to introduce a temporary variable. For example: tmp = skip_prefix(buf, "foo"); if (tmp) buf = tmp; 2. It is verbose to check the outcome in a conditional, as you need extra parentheses to silence compiler warnings. For example: if ((cp = skip_prefix(buf, "foo")) /* do something with cp */ Both of these make it harder to use for long if-chains, and we tend to use starts_with() instead. However, the first line of "do something" is often to then skip forward in buf past the prefix, either using a magic constant or with an extra strlen(3) (which is generally computed at compile time, but means we are repeating ourselves). This patch refactors skip_prefix() to return a simple boolean, and to provide the pointer value as an out-parameter. If the prefix is not found, the out-parameter is untouched. This lets you write: if (skip_prefix(arg, "foo ", &arg)) do_foo(arg); else if (skip_prefix(arg, "bar ", &arg)) do_bar(arg); Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-16Merge branch 'jk/error-resolve-conflict-advice'Libravatar Junio C Hamano1-5/+4
* jk/error-resolve-conflict-advice: error_resolve_conflict: drop quotations around operation error_resolve_conflict: rewrap advice message
2014-06-03error_resolve_conflict: drop quotations around operationLibravatar Jeff King1-1/+1
When you try to commit with unmerged entries, you get an error like: $ git commit error: 'commit' is not possible because you have unmerged files. The quotes around "commit" are clunky; the user doesn't care that this message is a template with the command-name filled in. Saying: error: commit is not possible because you have unmerged files is easier to read. As this code is called from other places, we may also end up with: $ git merge error: merge is not possible because you have unmerged files $ git cherry-pick foo error: cherry-pick is not possible because you have unmerged files $ git revert foo error: revert is not possible because you have unmerged files All of which look better without the quotes. This also happens to match the behavior of "git pull", which generates a similar message (but does not share code, as it is a shell script). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-03error_resolve_conflict: rewrap advice messageLibravatar Jeff King1-4/+3
If you try to commit with unresolved conflicts in the index, you get this message: $ git commit U foo error: 'commit' is not possible because you have unmerged files. hint: Fix them up in the work tree, hint: and then use 'git add/rm <file>' as hint: appropriate to mark resolution and make a commit, hint: or use 'git commit -a'. fatal: Exiting because of an unresolved conflict. The irregular line-wrapping makes this awkward to read, and it takes up more lines than necessary. Instead, let's rewrap it to about 60 characters per line: $ git commit U foo error: 'commit' is not possible because you have unmerged files. hint: Fix them up in the work tree, and then use 'git add/rm <file>' hint: as appropriate to mark resolution and make a commit, or use hint: 'git commit -a'. fatal: Exiting because of an unresolved conflict. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-07Merge branch 'jc/push-2.0-default-to-simple'Libravatar Junio C Hamano1-2/+0
Finally update the "git push" default behaviour to "simple".
2013-07-31Rename advice.object_name_warning to objectNameWarningLibravatar Thomas Rast1-1/+1
We spell config variables in camelCase instead of with_underscores. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-24Merge branch 'mm/rm-coalesce-errors'Libravatar Junio C Hamano1-0/+2
Give a single message followed by list of paths from "git rm" to report multiple paths that cannot be removed. * mm/rm-coalesce-errors: rm: introduce advice.rmHints to shorten messages rm: better error message on failure for multiple files
2013-06-18push: switch default from "matching" to "simple"Libravatar Junio C Hamano1-2/+0
We promised to change the behaviour of lazy "git push [there]" that does not say what to push on the command line from "matching" to "simple" in Git 2.0. This finally flips that bit. Helped-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-12rm: introduce advice.rmHints to shorten messagesLibravatar Mathieu Lienard--Mayor1-0/+2
Introduce advice.rmHints to choose whether to display advice or not when git rm fails. Defaults to true, in order to preserve current behavior. As an example, the message: error: 'foo.txt' has changes staged in the index (use --cached to keep the file, or -f to force removal) would look like, with advice.rmHints=false: error: 'foo.txt' has changes staged in the index Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr> Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-11Merge branch 'nd/warn-ambiguous-object-name'Libravatar Junio C Hamano1-0/+2
"git cmd <name>", when <name> happens to be a 40-hex string, directly uses the 40-hex string as an object name, even if a ref "refs/<some hierarchy>/<name>" exists. This disambiguation order is unlikely to change, but we should warn about the ambiguity just like we warn when more than one refs/ hierachies share the same name. * nd/warn-ambiguous-object-name: get_sha1: warn about full or short object names that look like refs
2013-05-29get_sha1: warn about full or short object names that look like refsLibravatar Nguyễn Thái Ngọc Duy1-0/+2
When we get 40 hex digits, we immediately assume it's an SHA-1. This is the right thing to do because we have no way else to specify an object. If there is a ref with the same object name, it will be ignored. Warn the user about this case because the ref with full object name is likely a mistake, for example git checkout -b $empty_var $(git rev-parse something) advice.object_name_warning is not documented because frankly people should not be aware about it until they encounter this situation. While at there, warn about ambiguation with abbreviated SHA-1 too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02branch: give advice when tracking start-point is missingLibravatar Jeff King1-0/+2
If the user requests to --set-upstream-to a branch that does not exist, then either: 1. It was a typo. 2. They thought the branch should exist. In case (1), there is not much we can do beyond showing the name we tried to use. For case (2), though, we can help to guide them through common workflows. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21Merge branch 'tb/document-status-u-tradeoff'Libravatar Junio C Hamano1-0/+2
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: advise to consider use of -u when read_directory takes too longLibravatar Nguyễn Thái Ngọc Duy1-0/+2
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-01-24push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCELibravatar Junio C Hamano1-0/+4
When we push to update an existing ref, if: * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, it won't be correct to suggest to fetch, integrate and push again, as the old and new objects will not "merge". We should explain that the push must be forced when there is a non-committish object is involved in such a case. If we do not have the current object at the tip of the remote, we do not even know that object, when fetched, is something that can be merged. In such a case, suggesting to pull first just like non-fast-forward case may not be technically correct, but in practice, most such failures are seen when you try to push your work to a branch without knowing that somebody else already pushed to update the same branch since you forked, so "pull first" would work as a suggestion most of the time. And if the object at the tip is not a commit, "pull first" will fail, without making any permanent damage. As a side effect, it also makes the error message the user will get during the next "push" attempt easier to understand, now the user is aware that a non-commit object is involved. In these cases, the current code already rejects such a push on the client end, but we used the same error and advice messages as the ones used when rejecting a non-fast-forward push, i.e. pull from there and integrate before pushing again. Introduce new rejection reasons and reword the messages appropriately. [jc: with help by Peff on message details] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-03push: allow already-exists advice to be disabledLibravatar Chris Rorvick1-0/+2
Add 'advice.pushAlreadyExists' option to disable the advice shown when an update is rejected for a reference that is not allowed to update at all (verses those that are allowed to fast-forward.) Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-03push: rename config variable for more general useLibravatar Chris Rorvick1-2/+5
The 'pushNonFastForward' advice config can be used to squelch several instances of push-related advice. Rename it to 'pushUpdateRejected' to cover other reject scenarios that are unrelated to fast-forwarding. Retain the old name for compatibility. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-24Merge branch 'jk/maint-advise-vaddf'Libravatar Junio C Hamano1-1/+1
The advise() function did not use varargs correctly to format its message. * jk/maint-advise-vaddf: advice: pass varargs to strbuf_vaddf, not strbuf_addf