1. 21 Mar, 2019 2 commits
    • Jeff King's avatar
      completion: fix multiple command removals · 057ab54b
      Jeff King authored
      Commit 6532f374 ("completion: allow to customize the completable
      command list", 2018-05-20) tried to allow multiple space-separated
      entries in completion.commands. To do this, it copies each parsed token
      into a strbuf so that the result is NUL-terminated.
      
      However, for tokens starting with "-", it accidentally passes the
      original non-terminated string, meaning that only the final one worked.
      Switch to using the strbuf.
      Reported-by: Todd Zullinger's avatarTodd Zullinger <tmz@pobox.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      057ab54b
    • Jeff King's avatar
      git: read local config in --list-cmds · 83b0ecf3
      Jeff King authored
      Normally code that is checking config before we've decided to do
      setup_git_directory() would use read_early_config(), which uses
      discover_git_directory() to tentatively see if we're in a repo,
      and if so to add it to the config sequence.
      
      But list_cmds() uses the caching configset mechanism which
      rightly does not use read_early_config(), because it has no
      idea if it's being called early.
      
      Call setup_git_directory_gently() so we can pick up repo-level
      config (like completion.commands).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      83b0ecf3
  2. 31 Jan, 2019 1 commit
    • Duy Nguyen's avatar
      help: align the longest command in the command listing · 6195a76d
      Duy Nguyen authored
      "longest" is used to determine how many extra spaces we need to print
      to keep the command description aligned. For the longest command, we
      should print no extra space instead of one, or we'll get unaligned
      output like this (notice the "checkout" line):
      
          grow, mark and tweak your common history
             branch     List, create, or delete branches
             checkout    Switch branches or restore working tree files
             commit     Record changes to the repository
             diff       Show changes between commits, commit and ...
             merge      Join two or more development histories together
             rebase     Reapply commits on top of another base tip
             tag        Create, list, delete or verify a tag ...
      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>
      6195a76d
  3. 12 Dec, 2018 1 commit
  4. 04 Oct, 2018 1 commit
    • Duy Nguyen's avatar
      help -a: improve and make --verbose default · 26c7d067
      Duy Nguyen authored
      When you type "git help" (or just "git") you are greeted with a list
      with commonly used commands and their short description and are
      suggested to use "git help -a" or "git help -g" for more details.
      
      "git help -av" would be more friendly and inline with what is shown
      with "git help" since it shows list of commands with description as
      well, and commands are properly grouped.
      
      "help -av" does not show everything "help -a" shows though. Add
      external command section in "help -av" for this. While at there, add a
      section for aliases as well (until now aliases have no UI, just "git
      config").
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Reviewed-by: default avatarTaylor Blau <me@ttaylorr.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      26c7d067
  5. 08 Aug, 2018 1 commit
    • Han-Wen Nienhuys's avatar
      sideband: highlight keywords in remote sideband output · bf1a11f0
      Han-Wen Nienhuys authored
      The colorization is controlled with the config setting "color.remote".
      
      Supported keywords are "error", "warning", "hint" and "success". They
      are highlighted if they appear at the start of the line, which is
      common in error messages, eg.
      
         ERROR: commit is missing Change-Id
      
      The Git push process itself prints lots of non-actionable messages
      (eg. bandwidth statistics, object counters for different phases of the
      process). This obscures actionable error messages that servers may
      send back. Highlighting keywords in the sideband draws more attention
      to those messages.
      
      The background for this change is that Gerrit does server-side
      processing to create or update code reviews, and actionable error
      messages (eg. missing Change-Id) must be communicated back to the user
      during the push. User research has shown that new users have trouble
      seeing these messages.
      
      The highlighting is done on the client rather than server side, so
      servers don't have to grow capabilities to understand terminal escape
      codes and terminal state. It also consistent with the current state
      where Git is control of the local display (eg. prefixing messages with
      "remote: ").
      
      The highlighting can be configured using color.remote.<KEYWORD>
      configuration settings. Since the keys are matched case insensitively,
      we match the keywords case insensitively too.
      
      Finally, this solution is backwards compatible: many servers already
      prefix their messages with "error", and they will benefit from this
      change without requiring a server update. By contrast, a server-side
      solution would likely require plumbing the TERM variable through the
      git protocol, so it would require changes to both server and client.
      Helped-by: Duy Nguyen's avatarDuy Nguyen <pclouds@gmail.com>
      Signed-off-by: default avatarHan-Wen Nienhuys <hanwen@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      bf1a11f0
  6. 27 Jul, 2018 1 commit
  7. 29 May, 2018 2 commits
  8. 21 May, 2018 5 commits
  9. 10 May, 2018 1 commit
    • Duy Nguyen's avatar
      help: use command-list.h for common command list · cfb22a02
      Duy Nguyen authored
      The previous commit added code generation for all_cmd_desc[] which
      includes almost everything we need to generate common command list.
      Convert help code to use that array instead and drop common_cmds[] array.
      
      The description of each common command group is removed from
      command-list.txt. This keeps this file format simpler. common-cmds.h
      will not be generated correctly after this change due to the
      command-list.txt format change. But it does not matter and
      common-cmds.h will be removed.
      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>
      cfb22a02
  10. 11 Apr, 2018 1 commit
  11. 15 Dec, 2017 2 commits
  12. 21 Jun, 2017 1 commit
    • Marc Branchaud's avatar
      auto-correct: tweak phrasing · 968b1fe2
      Marc Branchaud authored
      When help.autoCorrect is enabled, an invalid git command prints a
      warning and a continuation message, which differs depending on
      whether or not the value of help.autoCorrect is positive or
      negative.
      
      With help.autoCorrect = 15:
      
         WARNING: You called a Git command named 'lgo', which does not exist.
         Continuing under the assumption that you meant 'log'
         in 1.5 seconds automatically...
      
      With help.autoCorrect < 0:
      
         WARNING: You called a Git command named 'lgo', which does not exist.
         Continuing under the assumption that you meant 'log'
      
      The continuation message's phrasing is awkward.  This commit cleans it up.
      As a bonus, we now use full-sentence strings which make translation easier.
      
      With help.autoCorrect = 15:
      
         WARNING: You called a Git command named 'lgo', which does not exist.
         Continuing in 1.5 seconds, assuming that you meant 'log'.
      
      With help.autoCorrect < 0:
      
         WARNING: You called a Git command named 'lgo', which does not exist.
         Continuing under the assumption that you meant 'log'.
      Signed-off-by: default avatarMarc Branchaud <marcnarc@xiplink.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      968b1fe2
  13. 16 Jun, 2017 1 commit
  14. 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
    • Johannes Schindelin's avatar
      help: use early config when autocorrecting aliases · 659fef19
      Johannes Schindelin authored
      Git has this feature which suggests similar commands (including aliases)
      in case the user specified an unknown command.
      
      This feature currently relies on a side effect of the way we expand
      aliases right now: when a command is not a builtin, we use the regular
      config machinery (meaning: discovering the .git/ directory and
      initializing global state such as the config cache) to see whether the
      command refers to an alias.
      
      However, we will change the way aliases are expanded in the next
      commits, to use the early config instead. That means that the
      autocorrect feature can no longer discover the available aliases by
      looking at the config cache (because it has not yet been initialized).
      
      So let's just use the early config machinery instead.
      
      This is slightly less performant than the previous way, as the early
      config is used *twice*: once to see whether the command refers to an
      alias, and then to see what aliases are most similar. However, this is
      hardly a performance-critical code path, so performance is less important
      here.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      659fef19
  15. 05 Jun, 2017 1 commit
    • Jeff King's avatar
      version: convert to parse-options · b48cbfc5
      Jeff King authored
      The "git version" command didn't traditionally accept any
      options, and in fact ignores any you give it. When we added
      simple option parsing for "--build-options" in 6b9c38e1, we
      didn't improve this; we just loop over the arguments and
      pick out the one we recognize.
      
      Instead, let's move to a real parsing loop, complain about
      nonsense options, and recognize conventions like "-h".
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b48cbfc5
  16. 12 May, 2017 1 commit
    • Jean-Noël Avila's avatar
      usability: don't ask questions if no reply is required · 6c486862
      Jean-Noël Avila authored
      There has been a bug report by a corporate user that stated that
      "spelling mistake of stash followed by a yes prints character 'y'
      infinite times."
      
      This analysis was false. When the spelling of a command contains
      errors, the git program tries to help the user by providing candidates
      which are close to the unexisting command. E.g Git prints the
      following:
      
              git: 'stahs' is not a git command. See 'git --help'.
              Did you mean this?
      
              stash
      
      and then exits.
      
      The problem with this hint is that it is not formally indicated as an
      hint and the user is in fact encouraged to reply to the question,
      whereas the Git command is already finished.
      
      The user was unlucky enough that it was the command he was looking
      for, and replied "yes" on the command line, effectively launching the
      `yes` program.
      
      The initial error is that the Git programs, when launched in
      command-line mode (without interaction) must not ask questions,
      because these questions would normally require a user input as a reply
      that they won't handle indeed. That's a source of confusion on UX
      level.
      
      To improve the general usability of the Git suite, the following rule
      was applied:
      
      if the sentence
       * appears in a non-interactive session
       * is printed last before exit
       * is a question addressing the user ("you")
      
      the sentence is turned into affirmative and proposes the option.
      
      The basic rewording of the question sentences has been extended to
      other spots found in the source.
      
      Requested at https://github.com/git/git-scm.com/issues/999 by rpai1
      Signed-off-by: Jean-Noël Avila's avatarJean-Noel Avila <jn.avila@free.fr>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6c486862
  17. 26 Apr, 2017 1 commit
  18. 30 Jan, 2017 1 commit
    • Heiko Voigt's avatar
      help: improve is_executable() on Windows · c755015f
      Heiko Voigt authored
      On Windows, executables need to have the file extension `.exe`, or they
      are not executables. Hence, to support scripts, Git for Windows also
      looks for a she-bang line by opening the file in question, and executing
      it via the specified script interpreter.
      
      To figure out whether files in the `PATH` are executable, `git help` has
      code that imitates this behavior. With one exception: it *always* opens
      the files and looks for a she-bang line *or* an `MZ` tell-tale
      (nevermind that files with the magic `MZ` but without file extension
      `.exe` would still not be executable).
      
      Opening this many files leads to performance problems that are even more
      serious when a virus scanner is running. Therefore, let's change the
      code to look for the file extension `.exe` early, and avoid opening the
      file altogether if we already know that it is executable.
      
      See the following measurements (in seconds) as an example, where we
      execute a simple program that simply lists the directory contents and
      calls open() on every listed file:
      
      With virus scanner running (coldcache):
      
      $ ./a.exe /libexec/git-core/
      before open (git-add.exe): 0.000000
      after open (git-add.exe): 0.412873
      before open (git-annotate.exe): 0.000175
      after open (git-annotate.exe): 0.397925
      before open (git-apply.exe): 0.000243
      after open (git-apply.exe): 0.399996
      before open (git-archive.exe): 0.000147
      after open (git-archive.exe): 0.397783
      before open (git-bisect--helper.exe): 0.000160
      after open (git-bisect--helper.exe): 0.397700
      before open (git-blame.exe): 0.000160
      after open (git-blame.exe): 0.399136
      ...
      
      With virus scanner running (hotcache):
      
      $ ./a.exe /libexec/git-core/
      before open (git-add.exe): 0.000000
      after open (git-add.exe): 0.000325
      before open (git-annotate.exe): 0.000229
      after open (git-annotate.exe): 0.000177
      before open (git-apply.exe): 0.000167
      after open (git-apply.exe): 0.000150
      before open (git-archive.exe): 0.000154
      after open (git-archive.exe): 0.000156
      before open (git-bisect--helper.exe): 0.000132
      after open (git-bisect--helper.exe): 0.000180
      before open (git-blame.exe): 0.000718
      after open (git-blame.exe): 0.000724
      ...
      
      With this patch I get:
      
      $ time git help git
      Launching default browser to display HTML ...
      
      real    0m8.723s
      user    0m0.000s
      sys     0m0.000s
      
      and without
      
      $ time git help git
      Launching default browser to display HTML ...
      
      real    1m37.734s
      user    0m0.000s
      sys     0m0.031s
      
      both tests with cold cache and giving the machine some time to settle
      down after restart.
      
      [jes: adjusted the commit message]
      Signed-off-by: default avatarHeiko Voigt <heiko.voigt@mahr.de>
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c755015f
  19. 29 Sep, 2016 1 commit
  20. 15 Jul, 2016 1 commit
  21. 22 Feb, 2016 1 commit
  22. 05 Jun, 2015 1 commit
  23. 25 May, 2015 2 commits
  24. 21 May, 2015 1 commit
    • Sébastien Guimmara's avatar
      help: respect new common command grouping · 22414770
      Sébastien Guimmara authored
      'git help' shows common commands in alphabetical order:
      
      The most commonly used git commands are:
         add        Add file contents to the index
         bisect     Find by binary search the change that introduced a bug
         branch     List, create, or delete branches
         checkout   Checkout a branch or paths to the working tree
         clone      Clone a repository into a new directory
         commit     Record changes to the repository
         [...]
      
      without any indication of how commands relate to high-level
      concepts or each other. Revise the output to explain their relationship
      with the typical Git workflow:
      
        These are common Git commands used in various situations:
      
        start a working area (see also: git help tutorial)
           clone      Clone a repository into a new directory
           init       Create an empty Git repository or reinitialize [...]
      
        work on the current change (see also: git help everyday)
           add        Add file contents to the index
           reset      Reset current HEAD to the specified state
      
        examine the history and state (see also: git help revisions)
           log        Show commit logs
           status     Show the working tree status
      
           [...]
      Helped-by: Eric Sunshine's avatarEric Sunshine <sunshine@sunshineco.com>
      Signed-off-by: default avatarRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: default avatarSébastien Guimmara <sebastien.guimmara@gmail.com>
      Reviewed-by: Eric Sunshine's avatarEric Sunshine <sunshine@sunshineco.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      22414770
  25. 18 Sep, 2014 1 commit
  26. 30 Jun, 2014 2 commits
    • Jeff King's avatar
      use strip_suffix instead of ends_with in simple cases · 26936bfd
      Jeff King authored
      When stripping a suffix like:
      
        if (ends_with(str, "foo"))
      	buf = xmemdupz(str, strlen(str) - 3);
      
      we can instead use strip_suffix to avoid the constant 3,
      which must match the literal "foo" (we sometimes use
      strlen("foo") instead, but that means we are repeating
      ourselves). The example above becomes:
      
        if (strip_suffix(str, "foo", &len))
      	buf = xmemdupz(str, len);
      
      This also saves a strlen(), since we calculate the string
      length when detecting the suffix.
      
      Note that in some cases we also switch from xstrndup to
      xmemdupz, which saves a further strlen call.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      26936bfd
    • Jeff King's avatar
      replace has_extension with ends_with · 2975c770
      Jeff King authored
      These two are almost the same function, with the exception
      that has_extension only matches if there is content before
      the suffix. So ends_with(".exe", ".exe") is true, but
      has_extension would not be.
      
      This distinction does not matter to any of the callers,
      though, and we can just replace uses of has_extension with
      ends_with. We prefer the "ends_with" name because it is more
      generic, and there is nothing about the function that
      requires it to be used for file extensions.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2975c770
  27. 20 Jun, 2014 3 commits
    • Jeff King's avatar
      use skip_prefix to avoid repeated calculations · de8118e1
      Jeff King authored
      In some cases, we use starts_with to check for a prefix, and
      then use an already-calculated prefix length to advance a
      pointer past the prefix. There are no magic numbers or
      duplicated strings here, but we can still make the code
      simpler and more obvious by using skip_prefix.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      de8118e1
    • Jeff King's avatar
      use skip_prefix to avoid repeating strings · 95b567c7
      Jeff King authored
      It's a common idiom to match a prefix and then skip past it
      with strlen, like:
      
        if (starts_with(foo, "bar"))
      	  foo += strlen("bar");
      
      This avoids magic numbers, but means we have to repeat the
      string (and there is no compiler check that we didn't make a
      typo in one of the strings).
      
      We can use skip_prefix to handle this case without repeating
      ourselves.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      95b567c7
    • Jeff King's avatar
      use skip_prefix to avoid magic numbers · ae021d87
      Jeff King authored
      It's a common idiom to match a prefix and then skip past it
      with a magic number, like:
      
        if (starts_with(foo, "bar"))
      	  foo += 3;
      
      This is easy to get wrong, since you have to count the
      prefix string yourself, and there's no compiler check if the
      string changes.  We can use skip_prefix to avoid the magic
      numbers here.
      
      Note that some of these conversions could be much shorter.
      For example:
      
        if (starts_with(arg, "--foo=")) {
      	  bar = arg + 6;
      	  continue;
        }
      
      could become:
      
        if (skip_prefix(arg, "--foo=", &bar))
      	  continue;
      
      However, I have left it as:
      
        if (skip_prefix(arg, "--foo=", &v)) {
      	  bar = v;
      	  continue;
        }
      
      to visually match nearby cases which need to actually
      process the string. Like:
      
        if (skip_prefix(arg, "--foo=", &v)) {
      	  bar = atoi(v);
      	  continue;
        }
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ae021d87
  28. 28 Feb, 2014 1 commit