path: root/advice.c
AgeCommit message (Collapse)Author
2017-06-24Merge branch 'jk/warn-add-gitlink'Junio C Hamano
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 defaultBrandon Williams
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 <> Signed-off-by: Junio C Hamano <>
2017-06-15add: warn when adding an embedded repositoryJeff King
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 <> Signed-off-by: Junio C Hamano <>
2016-06-17i18n: advice: internationalize message for conflictsVasco Almeida
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, 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 <> Signed-off-by: Junio C Hamano <>
2016-06-17i18n: advice: mark string about detached head for translationVasco Almeida
Mark string with advice seen by the user when in detached head. Update test 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 <> Signed-off-by: Junio C Hamano <>
2015-10-02merge: grammofix in please-commit-before-merge messageAlex Henrie
Signed-off-by: Alex Henrie <> Signed-off-by: Junio C Hamano <>
2015-06-18pull: check if in unresolved merge statePaul Tan
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 <> Signed-off-by: Junio C Hamano <>
2015-01-14standardize usage info string formatAlex Henrie
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 <> Reviewed-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2014-08-28merge, pull: stop advising 'commit -a' in case of conflictMatthieu Moy
'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 <> Signed-off-by: Junio C Hamano <>
2014-06-20refactor skip_prefix to return a booleanJeff King
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 <> Signed-off-by: Junio C Hamano <>
2014-06-16Merge branch 'jk/error-resolve-conflict-advice'Junio C Hamano
* 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 operationJeff King
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 <> Signed-off-by: Junio C Hamano <>
2014-06-03error_resolve_conflict: rewrap advice messageJeff King
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 <> Signed-off-by: Junio C Hamano <>
2014-03-07Merge branch 'jc/push-2.0-default-to-simple'Junio C Hamano
Finally update the "git push" default behaviour to "simple".
2013-07-31Rename advice.object_name_warning to objectNameWarningThomas Rast
We spell config variables in camelCase instead of with_underscores. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2013-06-24Merge branch 'mm/rm-coalesce-errors'Junio C Hamano
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"Junio C Hamano
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 <> Signed-off-by: Junio C Hamano <>
2013-06-12rm: introduce advice.rmHints to shorten messagesMathieu Lienard--Mayor
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 <> Signed-off-by: Jorge Juan Garcia Garcia <> Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2013-06-11Merge branch 'nd/warn-ambiguous-object-name'Junio C Hamano
"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 refsNguyễn Thái Ngọc Duy
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 <> Signed-off-by: Junio C Hamano <>
2013-04-02branch: give advice when tracking start-point is missingJeff King
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 <> Signed-off-by: Junio C Hamano <>
2013-03-21Merge branch 'tb/document-status-u-tradeoff'Junio C Hamano
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-17status: advise to consider use of -u when read_directory takes too longNguyễn Thái Ngọc Duy
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 <> Signed-off-by: Junio C Hamano <>
2013-01-24push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCEJunio C Hamano
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 <>
2012-12-03push: allow already-exists advice to be disabledChris Rorvick
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 <> Signed-off-by: Junio C Hamano <>
2012-12-03push: rename config variable for more general useChris Rorvick
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 <> Signed-off-by: Junio C Hamano <>
2012-07-24Merge branch 'jk/maint-advise-vaddf'Junio C Hamano
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
2012-07-23advice: pass varargs to strbuf_vaddf, not strbuf_addfJeff King
The advise() function takes a variable number of arguments and converts them into a va_list object to pass to strbuf for handling. However, we accidentally called strbuf_addf (that takes a variable number of arguments) instead of strbuf_vaddf (that takes a va_list). This bug dates back to v1.7.8.1-1-g23cb5bf, but we never noticed because none of the current callers passes a string with a format specifier in it. And the compiler did not notice because the format string is not available at compile time. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-03-20push: Provide situational hints for non-fast-forward errorsChristopher Tiwald
Pushing a non-fast-forward update to a remote repository will result in an error, but the hint text doesn't provide the correct resolution in every case. Give better resolution advice in three push scenarios: 1) If you push your current branch and it triggers a non-fast-forward error, you should merge remote changes with 'git pull' before pushing again. 2) If you push to a shared repository others push to, and your local tracking branches are not kept up to date, the 'matching refs' default will generate non-fast-forward errors on outdated branches. If this is your workflow, the 'matching refs' default is not for you. Consider setting the 'push.default' configuration variable to 'current' or 'upstream' to ensure only your current branch is pushed. 3) If you explicitly specify a ref that is not your current branch or push matching branches with ':', you will generate a non-fast-forward error if any pushed branch tip is out of date. You should checkout the offending branch and merge remote changes before pushing again. Teach transport.c to recognize these scenarios and configure push.c to hint for them. If 'git push's default behavior changes or we discover more scenarios, extension is easy. Standardize on the advice API and add three new advice variables, 'pushNonFFCurrent', 'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these to 'false' will disable their affiliated advice. Setting 'pushNonFastForward' to false will disable all three, thus preserving the config option for users who already set it, but guaranteeing new users won't disable push advice accidentally. Based-on-patch-by: Junio C Hamano <> Signed-off-by: Christopher Tiwald <> Signed-off-by: Junio C Hamano <>
2012-02-01Merge branch 'nd/clone-detached'Junio C Hamano
* nd/clone-detached: clone: fix up delay cloning conditions push: do not let configured foreign-vcs permanently clobbered clone: print advice on checking out detached HEAD clone: allow --branch to take a tag clone: refuse to clone if --branch points to bogus ref clone: --branch=<branch> always means refs/heads/<branch> clone: delay cloning until after remote HEAD checking clone: factor out remote ref writing clone: factor out HEAD update code clone: factor out checkout code clone: write detached HEAD in bare repositories t5601: add missing && cascade
2012-01-17clone: print advice on checking out detached HEADNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2011-12-22i18n of multi-line advice messagesJunio C Hamano
Advice messages are by definition meant for human end-users, and prime candidates for i18n/l10n. They tend to also be more verbose to be helpful, and need to be longer than just one line. Although we do not have parameterized multi-line advice messages yet, once we do, we cannot emit such a message like this: advise(_("Please rename %s to something else"), gostak); advise(_("so that we can avoid distimming %s unnecessarily."), doshes); because some translations may need to have the replacement of 'gostak' on the second line (or 'doshes' on the first line). Some languages may even need to use three lines in order to fit the same message within a reasonable width. Instead, it has to be a single advise() construct, like this: advise(_("Please rename %s to something else\n" "so that we can avoid distimming %s unnecessarily."), gostak, doshes); Update the advise() function and its existing callers to - take a format string that can be multi-line and translatable as a whole; - use the string and the parameters to form a localized message; and - show each line in the result with the localization of the "hint: ". Signed-off-by: Junio C Hamano <>
2011-08-04advice: Introduce error_resolve_conflictRamkumar Ramachandra
Enable future callers to report a conflict and not die immediately by introducing a new function called error_resolve_conflict. Re-implement die_resolve_conflict as a call to error_resolve_conflict followed by a call to die. Consequently, the message printed by die_resolve_conflict changes from fatal: 'commit' is not possible because you have unmerged files. Please, fix them up in the work tree ... ... to error: 'commit' is not possible because you have unmerged files. hint: Fix them up in the work tree ... hint: ... fatal: Exiting because of an unresolved conflict. Hints are printed using the same advise function introduced in v1.7.3-rc0~26^2~3 (Introduce advise() to print hints, 2010-08-11). Inspired-by: Christian Couder <> Helped-by: Jonathan Nieder <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Ramkumar Ramachandra <> Signed-off-by: Junio C Hamano <>
2010-01-30Reword "detached HEAD" notificationJunio C Hamano
The old "advice" message explained how to create a branch after going into a detached HEAD state but didn't make it clear why the user may want to do so. Also "moving to ... which isn't a local branch" was unclear if it is complaining, if it is describing the new state, or if it is explaining why the HEAD is detached (the true reason is the last one). Give the established phrase 'detached HEAD' first to make it easy for users to look up the concept in documentation, and briefly describe what can be done in the state (i.e. play around without having to clean up) before telling the user how to keep what was done during the temporary state. Allow the long description to be hidden by setting advice.detachedHead configuration to false. We might want to customize the advice depending on how the commit to check out was spelled (e.g. instead of "new-branch-name", we way want to say "topic" when "git checkout origin/topic" triggered this message) in later updates, but this encapsulates that into a separate function and it should be a good first step. Signed-off-by: Junio C Hamano <>
2010-01-20Merge branch 'mm/conflict-advice'Junio C Hamano
* mm/conflict-advice: Be more user-friendly when refusing to do something because of conflict. Conflicts: Documentation/config.txt advice.c advice.h
2010-01-14commit: allow suppression of implicit identity adviceJeff King
We now nag the user with a giant warning when their identity was pulled from the username, hostname, and gecos information, in case it is not correct. Most users will suppress this by simply setting up their information correctly. However, there may be some users who consciously want to use that information, because having the value change from host to host contains useful information. These users can now set advice.implicitidentity to false to suppress the message. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2010-01-12Be more user-friendly when refusing to do something because of conflict.Matthieu Moy
Various commands refuse to run in the presence of conflicts (commit, merge, pull, cherry-pick/revert). They all used to provide rough, and inconsistant error messages. A new variable advice.resolveconflict is introduced, and allows more verbose messages, pointing the user to the appropriate solution. For commit, the error message used to look like this: $ git commit foo.txt: needs merge foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169) foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030) foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4) error: Error building trees The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN option to make the output more consistant with the other porcelain commands, and catch the error in return, to stop with a clean error message. The next lines were displayed by a call to cache_tree_update(), which is not reached anymore if we noticed the conflict. The new output looks like: U foo.txt fatal: 'commit' is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm <file>' as appropriate to mark resolution and make a commit, or use 'git commit -a'. Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD exists instead of waiting for merge to complain. The behavior of merge and the test-case are slightly modified to reflect the usual flow: start with conflicts, fix them, and afterwards get rid of MERGE_HEAD, with different error messages at each stage. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2009-11-23merge-recursive: point the user to commit when file would be overwritten.Matthieu Moy
The commit-before-pull is well accepted in the DVCS community, but is confusing some new users. This should get them back in the right way when the problem occurs. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2009-09-12status: make "how to stage" messages optionalJeff King
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 <> Signed-off-by: Junio C Hamano <>
2009-09-12push: make non-fast-forward help message configurableJeff King
This message is designed to help new users understand what has happened when refs fail to push. However, it does not help experienced users at all, and significantly clutters the output, frequently dwarfing the regular status table and making it harder to see. This patch introduces a general configuration mechanism for optional messages, with this push message as the first example. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>