1. 14 Nov, 2018 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      push: add an advice on unqualified <dst> push · dd8dd300
      Ævar Arnfjörð Bjarmason authored
      Add an advice to the recently improved error message added in
      f8aae120 ("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's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      dd8dd300
  2. 24 Oct, 2018 1 commit
  3. 11 Jun, 2018 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      checkout: add advice for ambiguous "checkout <branch>" · ad8d5104
      Ævar Arnfjörð Bjarmason authored
      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's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ad8d5104
  4. 29 May, 2018 3 commits
  5. 30 Apr, 2018 1 commit
    • Johannes Schindelin's avatar
      Deprecate support for .git/info/grafts · f9f99b3f
      Johannes Schindelin authored
      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 4228e8bc
      (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's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Reviewed-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f9f99b3f
  6. 24 Apr, 2018 1 commit
    • Ryan Dammrose's avatar
      push: colorize errors · 960786e7
      Ryan Dammrose authored
      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's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      960786e7
  7. 07 Dec, 2017 1 commit
    • Lars Schneider's avatar
      launch_editor(): indicate that Git waits for user input · abfb04d0
      Lars Schneider authored
      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: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: default avatarLars Schneider <larsxschneider@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      abfb04d0
  8. 10 Oct, 2017 1 commit
    • Damien's avatar
      run-command: add hint when a hook is ignored · f805a00a
      Damien authored
      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's avatarDamien Marié <damien@dam.io>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f805a00a
  9. 15 Jun, 2017 2 commits
    • Brandon Williams's avatar
      config: don't include config.h by default · b2141fc1
      Brandon Williams authored
      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: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b2141fc1
    • Jeff King's avatar
      add: warn when adding an embedded repository · 53213994
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      53213994
  10. 17 Jun, 2016 2 commits
  11. 02 Oct, 2015 1 commit
  12. 18 Jun, 2015 1 commit
    • Paul Tan's avatar
      pull: check if in unresolved merge state · 4a4cf9e8
      Paul Tan authored
      Since d38a30df (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: default avatarPaul Tan <pyokagan@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4a4cf9e8
  13. 14 Jan, 2015 1 commit
  14. 28 Aug, 2014 1 commit
    • Matthieu Moy's avatar
      merge, pull: stop advising 'commit -a' in case of conflict · 91e70e00
      Matthieu Moy authored
      '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: default avatarMatthieu Moy <Matthieu.Moy@imag.fr>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      91e70e00
  15. 20 Jun, 2014 1 commit
    • Jeff King's avatar
      refactor skip_prefix to return a boolean · cf4fff57
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      cf4fff57
  16. 03 Jun, 2014 2 commits
    • Jeff King's avatar
      error_resolve_conflict: drop quotations around operation · d795216a
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d795216a
    • Jeff King's avatar
      error_resolve_conflict: rewrap advice message · c057b242
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c057b242
  17. 13 Nov, 2013 1 commit
  18. 31 Jul, 2013 1 commit
  19. 18 Jun, 2013 1 commit
  20. 12 Jun, 2013 1 commit
  21. 29 May, 2013 1 commit
    • Duy Nguyen's avatar
      get_sha1: warn about full or short object names that look like refs · 798c35fc
      Duy Nguyen authored
      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: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      798c35fc
  22. 02 Apr, 2013 1 commit
  23. 17 Mar, 2013 1 commit
  24. 24 Jan, 2013 1 commit
    • Junio C Hamano's avatar
      push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE · 75e5c0dc
      Junio C Hamano authored
      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: default avatarJunio C Hamano <gitster@pobox.com>
      75e5c0dc
  25. 03 Dec, 2012 2 commits
  26. 23 Jul, 2012 1 commit
    • Jeff King's avatar
      advice: pass varargs to strbuf_vaddf, not strbuf_addf · 447b99c8
      Jeff King authored
      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-g23cb5bf3, 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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      447b99c8
  27. 20 Mar, 2012 1 commit
    • Christopher Tiwald's avatar
      push: Provide situational hints for non-fast-forward errors · f25950f3
      Christopher Tiwald authored
      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: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: default avatarChristopher Tiwald <christiwald@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f25950f3
  28. 17 Jan, 2012 1 commit
  29. 22 Dec, 2011 1 commit
    • Junio C Hamano's avatar
      i18n of multi-line advice messages · 23cb5bf3
      Junio C Hamano authored
      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: default avatarJunio C Hamano <gitster@pobox.com>
      23cb5bf3
  30. 04 Aug, 2011 1 commit
  31. 30 Jan, 2010 1 commit
    • Junio C Hamano's avatar
      Reword "detached HEAD" notification · 13be3e31
      Junio C Hamano authored
      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: default avatarJunio C Hamano <gitster@pobox.com>
      13be3e31
  32. 14 Jan, 2010 1 commit
    • Jeff King's avatar
      commit: allow suppression of implicit identity advice · b706fcfe
      Jeff King authored
      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: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b706fcfe
  33. 12 Jan, 2010 1 commit
    • Matthieu Moy's avatar
      Be more user-friendly when refusing to do something because of conflict. · d38a30df
      Matthieu Moy authored
      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: default avatarMatthieu Moy <Matthieu.Moy@imag.fr>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d38a30df
  34. 23 Nov, 2009 1 commit