1. 22 Feb, 2019 1 commit
  2. 21 May, 2018 1 commit
  3. 13 May, 2018 1 commit
    • Jeff King's avatar
      pager: set COLUMNS to term_columns() · be11f7ad
      Jeff King authored
      After we invoke the pager, our stdout goes to a pipe, not the
      terminal, meaning we can no longer use an ioctl to get the
      terminal width. For that reason, ad6c3739 (pager: find out
      the terminal width before spawning the pager, 2012-02-12)
      started caching the terminal width.
      
      But that cache is only an in-process variable. Any programs
      we spawn will also not be able to run that ioctl, but won't
      have access to our cache. They'll end up falling back to our
      80-column default.
      
      You can see the problem with:
      
        git tag --column=row
      
      Since git-tag spawns a pager these days, its spawned
      git-column helper will see neither the terminal on stdout
      nor a useful COLUMNS value (assuming you do not export it
      from your shell already). And you'll end up with 80-column
      output in the pager, regardless of your terminal size.
      
      We can fix this by setting COLUMNS right before spawning the
      pager. That fixes this case, as well as any more complicated
      ones (e.g., a paged program spawns another script which then
      generates columnized output).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      be11f7ad
  4. 07 Aug, 2017 1 commit
  5. 15 Jun, 2017 1 commit
  6. 24 Mar, 2017 1 commit
  7. 14 Mar, 2017 1 commit
  8. 13 Sep, 2016 5 commits
    • Jeff King's avatar
      pager: handle early config · eed27072
      Jeff King authored
      The pager code is often run early in the git.c startup,
      before we have actually found the repository. When we ask
      git_config() to look for values like core.pager, it doesn't
      know where to find the repo-level config, and will blindly
      examine ".git/config" if it exists. That's why t7006 shows
      that many pager-related features happen to work from the
      top-level of a repository, but not from a subdirectory.
      
      This patch pulls that ".git/config" hack explicitly into the
      pager code. There are two reasons for this:
      
        1. We'd like to clean up the git_config() behavior, as
           looking at ".git/config" when we do not have a
           configured repository is often the wrong thing to do.
           But we'd prefer not to break the pager config any worse
           than it already is.
      
        2. It's one very tiny step on the road to ultimately
           making the pager config work consistently. If we
           eventually get an equivalent of setup_git_directory()
           that _just_ finds the directory and doesn't chdir() or
           set up any global state, we could plug it in here
           (instead of blindly looking at ".git/config").
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      eed27072
    • Jeff King's avatar
      pager: use callbacks instead of configset · 6a1e1bc0
      Jeff King authored
      While the cached configset interface is more pleasant to
      use, it is not appropriate for "early" config like pager
      setup, which must sometimes do tricky things like reading
      from ".git/config" even when we have not set up the
      repository.
      
      As a preparatory step to handling these cases better, let's
      switch back to using the callback interface, which gives us
      more control.
      
      Note that this is essentially a revert of 586f414a (pager.c:
      replace `git_config()` with `git_config_get_value()`,
      2014-08-07), but with some minor style fixups and
      modernizations.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6a1e1bc0
    • Jeff King's avatar
      pager: make pager_program a file-local static · c0c08897
      Jeff King authored
      This variable is only ever used by the routines in pager.c,
      and other parts of the code should always use those routines
      (like git_pager()) to make decisions about which pager to
      use. Let's reduce its scope to prevent accidents.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c0c08897
    • Jeff King's avatar
      pager: stop loading git_default_config() · 4babb839
      Jeff King authored
      In git_pager(), we really only care about getting the value
      of core.pager. But to do so, we use the git_default_config()
      callback, which loads many other values. Ordinarily it
      isn't a big deal to load this config an extra time, as it
      simply overwrites the values from the previous run. But it's
      a bad idea here, for two reasons:
      
        1. The pager setup may be called very early in the
           program, before we have found the git repository. As a
           result, we may fail to read the correct repo-level
           config file.  This is a problem for core.pager, too,
           but we should at least try to minimize the pollution to
           other configured values.
      
        2. Because we call setup_pager() from git.c, basically
           every builtin command _may_ end up reading this config
           and getting an implicit git_default_config() setup.
      
           Which doesn't sound like a terrible thing, except that
           we don't do it consistently; it triggers only when
           stdout is a tty. So if a command forgets to load the
           default config itself (but depends on it anyway), it
           may appear to work, and then mysteriously fail when the
           pager is not in use.
      
      We can improve this by loading _just_ the core.pager config
      from git_pager().
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4babb839
    • Jeff King's avatar
      pager: remove obsolete comment · 01e7e903
      Jeff King authored
      The comment at the top of pager.c claims that we've split
      the code out so that Windows can do something different.
      This dates back to f67b45f8 (Introduce trivial new pager.c
      helper infrastructure, 2006-02-28), because the original
      implementation used fork(). Later, we ended up sticking the
      Windows #ifdefs into this file anyway. And then even later,
      in ea27a18c (spawn pager via run_command interface,
      2008-07-22) we unified the implementations.
      
      So these days this comment is really saying nothing at all.
      Let's drop it.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      01e7e903
  9. 04 Aug, 2016 1 commit
  10. 17 Feb, 2016 1 commit
  11. 16 Feb, 2016 1 commit
  12. 04 Sep, 2015 1 commit
    • Takashi Iwai's avatar
      pager: don't use unsafe functions in signal handlers · 507d7804
      Takashi Iwai authored
      Since the commit a3da8821 (pager: do wait_for_pager on signal
      death), we call wait_for_pager() in the pager's signal handler.  The
      recent bug report revealed that this causes a deadlock in glibc at
      aborting "git log" [*1*].  When this happens, git process is left
      unterminated, and it can't be killed by SIGTERM but only by SIGKILL.
      
      The problem is that wait_for_pager() function does more than waiting
      for pager process's termination, but it does cleanups and printing
      errors.  Unfortunately, the functions that may be used in a signal
      handler are very limited [*2*].  Particularly, malloc(), free() and the
      variants can't be used in a signal handler because they take a mutex
      internally in glibc.  This was the cause of the deadlock above.  Other
      than the direct calls of malloc/free, many functions calling
      malloc/free can't be used.  strerror() is such one, either.
      
      Also the usage of fflush() and printf() in a signal handler is bad,
      although it seems working so far.  In a safer side, we should avoid
      them, too.
      
      This patch tries to reduce the calls of such functions in signal
      handlers.  wait_for_signal() takes a flag and avoids the unsafe
      calls.   Also, finish_command_in_signal() is introduced for the
      same reason.  There the free() calls are removed, and only waits for
      the children without whining at errors.
      
      [*1*] https://bugzilla.opensuse.org/show_bug.cgi?id=942297
      [*2*] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      507d7804
  13. 24 Aug, 2015 1 commit
    • Jeff King's avatar
      config: silence warnings for command names with invalid keys · 9e9de18f
      Jeff King authored
      When we are running the git command "foo", we may have to
      look up the config keys "pager.foo" and "alias.foo". These
      config schemes are mis-designed, as the command names can be
      anything, but the config syntax has some restrictions. For
      example:
      
        $ git foo_bar
        error: invalid key: pager.foo_bar
        error: invalid key: alias.foo_bar
        git: 'foo_bar' is not a git command. See 'git --help'.
      
      You cannot name an alias with an underscore. And if you have
      an external command with one, you cannot configure its
      pager.
      
      In the long run, we may develop a different config scheme
      for these features. But in the near term (and because we'll
      need to support the existing scheme indefinitely), we should
      at least squelch the error messages shown above.
      
      These errors come from git_config_parse_key. Ideally we
      would pass a "quiet" flag to the config machinery, but there
      are many layers between the pager code and the key parsing.
      Passing a flag through all of those would be an invasive
      change.
      
      Instead, let's provide a config function to report on
      whether a key is syntactically valid, and have the pager and
      alias code skip lookup for bogus keys. We can build this
      easily around the existing git_config_parse_key, with two
      minor modifications:
      
        1. We now handle a NULL store_key, to validate but not
           write out the normalized key.
      
        2. We accept a "quiet" flag to avoid writing to stderr.
           This doesn't need to be a full-blown public "flags"
           field, because we can make the existing implementation
           a static helper function, keeping the mess contained
           inside config.c.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9e9de18f
  14. 04 Jul, 2015 1 commit
    • Junio C Hamano's avatar
      pager: do not leak "GIT_PAGER_IN_USE" to the pager · 124b5190
      Junio C Hamano authored
      Since 2e6c012e (setup_pager: set GIT_PAGER_IN_USE, 2011-08-17), we
      export GIT_PAGER_IN_USE so that a process that becomes the upstream
      of the spawned pager can still tell that we have spawned the pager
      and decide to do colored output even when its output no longer goes
      to a terminal (i.e. isatty(1)).
      
      But we forgot to clear it from the enviornment of the spawned pager.
      
      This is not a problem in a sane world, but if you have a handful of
      thousands Git users in your organization, somebody is bound to do
      strange things, e.g. typing "!<ENTER>" instead of 'q' to get control
      back from $LESS.  GIT_PAGER_IN_USE is still set in that subshell
      spawned by "less", and all sorts of interesting things starts
      happening, e.g. "git diff | cat" starts coloring its output.
      
      We can clear the environment variable in the half of the fork that
      runs the pager to avoid the confusion.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      Acked-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      124b5190
  15. 05 Feb, 2015 1 commit
    • Jeff King's avatar
      decimal_width: avoid integer overflow · d306f3d3
      Jeff King authored
      The decimal_width function originally appeared in blame.c as
      "lineno_width", and was designed for calculating the
      print-width of small-ish integer values (line numbers in
      text files). In ec7ff5ba, it was made into a reusable
      function, and in dc801e71, we started using it to align
      diffstats.
      
      Binary files in a diffstat show byte counts rather than line
      numbers, meaning they can be quite large (e.g., consider
      adding or removing a 2GB file). decimal_width is not up to
      the challenge for two reasons:
      
        1. It takes the value as an "int", whereas large files may
           easily surpass this. The value may be truncated, in
           which case we will produce an incorrect value.
      
        2. It counts "up" by repeatedly multiplying another
           integer by 10 until it surpasses the value.  This can
           cause an infinite loop when the value is close to the
           largest representable integer.
      
           For example, consider using a 32-bit signed integer,
           and a value of 2,140,000,000 (just shy of 2^31-1).
           We will count up and eventually see that 1,000,000,000
           is smaller than our value. The next step would be to
           multiply by 10 and see that 10,000,000,000 is too
           large, ending the loop. But we can't represent that
           value, and we have signed overflow.
      
           This is technically undefined behavior, but a common
           behavior is to lose the high bits, in which case our
           iterator will certainly be less than the number. So
           we'll keep multiplying, overflow again, and so on.
      
      This patch changes the argument to a uintmax_t (the same
      type we use to store the diffstat information for binary
      filese), and counts "down" by repeatedly dividing our value
      by 10.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d306f3d3
  16. 19 Oct, 2014 1 commit
  17. 20 Aug, 2014 1 commit
  18. 07 Aug, 2014 1 commit
  19. 07 May, 2014 1 commit
    • Matthieu Moy's avatar
      pager: remove 'S' from $LESS by default · b3275838
      Matthieu Moy authored
      By default, Git used to set $LESS to -FRSX if $LESS was not set by
      the user. The FRX flags actually make sense for Git (F and X because
      sometimes the output Git pipes to less is short, and R because Git
      pipes colored output). The S flag (chop long lines), on the other
      hand, is not related to Git and is a matter of user preference. Git
      should not decide for the user to change LESS's default.
      
      More specifically, the S flag harms users who review untrusted code
      within a pager, since a patch looking like:
      
          -old code;
          +new good code; [... lots of tabs ...] malicious code;
      
      would appear identical to:
      
          -old code;
          +new good code;
      
      Users who prefer the old behavior can still set the $LESS environment
      variable to -FRSX explicitly, or set core.pager to 'less -S'.
      
      The documentation in config.txt is made a bit longer to keep both an
      example setting the 'S' flag (needed to recover the old behavior)
      and an example showing how to unset a flag set by Git.
      Signed-off-by: default avatarMatthieu Moy <Matthieu.Moy@imag.fr>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b3275838
  20. 28 Apr, 2014 1 commit
  21. 07 Jan, 2014 1 commit
    • Jonathan Nieder's avatar
      pager: set LV=-c alongside LESS=FRSX · e54c1f2d
      Jonathan Nieder authored
      On systems with lv configured as the preferred pager (i.e.,
      DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the
      environment) git commands that use color show control codes instead of
      color in the pager:
      
      	$ git diff
      	^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m
      	^[[1mindex aa4f0b2..17e113e 100644^[[m
      	^[[1m--- a/.mailfilter^[[m
      	^[[1m+++ b/.mailfilter^[[m
      	^[[36m@@ -1,11 +1,58 @@^[[m
      
      "less" avoids this problem because git uses the LESS environment
      variable to pass the -R option ('output ANSI color escapes in raw
      form') by default.  Use the LV environment variable to pass 'lv' the
      -c option ('allow ANSI escape sequences for text decoration / color')
      to fix it for lv, too.
      
      Noticed when the default value for color.ui flipped to 'auto' in
      v1.8.4-rc0~36^2~1 (2013-06-10).
      Reported-by: default avatarOlaf Meeuwissen <olaf.meeuwissen@avasys.jp>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e54c1f2d
  22. 05 Dec, 2013 1 commit
    • Christian Couder's avatar
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      Christian Couder authored
      Leaving only the function definitions and declarations so that any
      new topic in flight can still make use of the old functions, replace
      existing uses of the prefixcmp() and suffixcmp() with new API
      functions.
      
      The change can be recreated by mechanically applying this:
      
          $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
            grep -v strbuf\\.c |
            xargs perl -pi -e '
              s|!prefixcmp\(|starts_with\(|g;
              s|prefixcmp\(|!starts_with\(|g;
              s|!suffixcmp\(|ends_with\(|g;
              s|suffixcmp\(|!ends_with\(|g;
            '
      
      on the result of preparatory changes in this series.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      59556548
  23. 03 Sep, 2013 1 commit
    • Jeff King's avatar
      pager: turn on "cat" optimization for DEFAULT_PAGER · ed016612
      Jeff King authored
      If the user specifies a pager of "cat" (or the empty
      string), whether it is in the environment or from config, we
      automagically optimize it out to mean "no pager" and avoid
      forking at all. We treat an empty pager variable similary.
      
      However, we did not apply this optimization when
      DEFAULT_PAGER was set to "cat" (or the empty string). There
      is no reason to treat DEFAULT_PAGER any differently. The
      optimization should not be user-visible (unless the user has
      a bizarre "cat" in their PATH). And even if it is, we are
      better off behaving consistently between the compile-time
      default and the environment and config settings.
      
      The stray "else" we are removing from this code was
      introduced by 402461aa (pager: do not fork a pager if PAGER
      is set to empty., 2006-04-16). At that time, the line
      directly above used:
      
         if (!pager)
      	   pager = "less";
      
      as a fallback, meaning that it could not possibly trigger
      the optimization. Later, a3d023d0 (Provide a build time
      default-pager setting, 2009-10-30) turned that constant into
      a build-time setting which could be anything, but didn't
      loosen the "else" to let DEFAULT_PAGER use the optimization.
      Noticed-by: default avatarDale R. Worley <worley@alum.mit.edu>
      Suggested-by: Matthieu Moy's avatarMatthieu Moy <Matthieu.Moy@grenoble-inp.fr>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ed016612
  24. 29 Oct, 2012 1 commit
  25. 05 Jun, 2012 1 commit
    • Jeff King's avatar
      pager: drop "wait for output to run less" hack · e8320f35
      Jeff King authored
      Commit 35ce8622 (pager: Work around window resizing bug in
      'less', 2007-01-24) causes git's pager sub-process to wait
      to receive input after forking but before exec-ing the
      pager. To handle this, run-command had to grow a "pre-exec
      callback" feature. Unfortunately, this feature does not work
      at all on Windows (where we do not fork), and interacts
      poorly with run-command's parent notification system. Its
      use should be discouraged.
      
      The bug in less was fixed in version 406, which was released
      in June 2007. It is probably safe at this point to remove
      our workaround. That lets us rip out the preexec_cb feature
      entirely.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e8320f35
  26. 27 Apr, 2012 1 commit
    • Duy Nguyen's avatar
      Stop starting pager recursively · 88e8f908
      Duy Nguyen authored
      git-column can be used as a pager for other git commands, something
      like this:
      
          GIT_PAGER="git -p column --mode='dense color'" git -p branch
      
      The problem with this is that "git -p column" also has $GIT_PAGER set so
      the pager runs itself again as another pager. The end result is an
      infinite loop of forking. Other git commands have the same problem if
      being abused this way.
      
      Check if $GIT_PAGER is already set and stop launching another pager.
      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>
      88e8f908
  27. 15 Feb, 2012 1 commit
  28. 13 Feb, 2012 1 commit
  29. 18 Aug, 2011 1 commit
    • Jeff King's avatar
      setup_pager: set GIT_PAGER_IN_USE · 2e6c012e
      Jeff King authored
      We have always set a global "spawned_pager" variable when we
      start the pager. This lets us make the auto-color decision
      later in the program as as "we are outputting to a terminal,
      or to a pager which can handle colors".
      
      Commit 6e9af863 added support for the GIT_PAGER_IN_USE
      environment variable. An external program calling git (e.g.,
      git-svn) could set this variable to indicate that it had
      already started the pager, and that the decision about
      auto-coloring should take that into account.
      
      However, 6e9af863 failed to do the reverse, which is to tell
      external programs when git itself has started the pager.
      Thus a git command implemented as an external script that
      has the pager turned on (e.g., "git -p stash show") would
      not realize it was going to a pager, and would suppress
      colors.
      
      This patch remedies that; we always set GIT_PAGER_IN_USE
      when we start the pager, and the value is respected by both
      this program and any spawned children.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2e6c012e
  30. 15 Feb, 2010 1 commit
    • Jonathan Nieder's avatar
      Make 'git var GIT_PAGER' always print the configured pager · 64778d24
      Jonathan Nieder authored
      Scripted commands that want to use git’s configured pager know better
      than ‘git var’ does whether stdout is going to be a tty at the
      appropriate time.  Checking isatty(1) as git_pager() does now won’t
      cut it, since the output of git var itself is almost never a terminal.
      The symptom is that when used by humans, ‘git var GIT_PAGER’ behaves
      as it should, but when used by scripts, it always returns ‘cat’!
      
      So avoid tricks with isatty() and just always print the configured
      pager.
      
      This does not fix the callers to check isatty(1) themselves yet.
      Nevertheless, this patch alone is enough to fix 'am --interactive'.
      
      Thanks to Sebastian Celis for the report and Jeff King for the
      analysis.
      Reported-by: default avatarSebastian Celis <sebastian@sebastiancelis.com>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      64778d24
  31. 06 Jan, 2010 1 commit
  32. 13 Nov, 2009 2 commits
  33. 19 Sep, 2009 1 commit
  34. 11 Sep, 2009 1 commit
  35. 22 Jan, 2009 1 commit
    • Jeff King's avatar
      pager: do wait_for_pager on signal death · a3da8821
      Jeff King authored
      Since ea27a18c (spawn pager via run_command interface), the
      original git process actually does git work, and the pager
      is a child process (actually, on Windows it has always been
      that way, since Windows lacks fork). After spawning the
      pager, we register an atexit() handler that waits for the
      pager to finish.
      
      Unfortunately, that handler does not always run. In
      particular, if git is killed by a signal, then we exit
      immediately. The calling shell then thinks that git is done;
      however, the pager is still trying to run and impact the
      terminal. The result can be seen by running a long git
      process with a pager (e.g., "git log -p") and hitting ^C.
      Depending on your config, you should see the shell prompt,
      but pressing a key causes the pager to do any terminal
      de-initialization sequence.
      
      This patch just intercepts any death-dealing signals and
      waits for the pager before dying. Under typical less
      configuration, that means hitting ^C will cause git to stop
      generating output, but the pager will keep running.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a3da8821