1. 07 Mar, 2019 1 commit
  2. 20 Dec, 2016 1 commit
    • Junio C Hamano's avatar
      i18n: fix misconversion in shell scripts · acefe2be
      Junio C Hamano authored
      An earlier series that was merged at 2703572b ("Merge branch
      'va/i18n-even-more'", 2016-07-13) failed to use $(eval_gettext
      "string with \$variable interpolation") and instead used gettext in
      a few places, and ended up showing the variable names in the
      message, e.g.
      
          $ git submodule
          fatal: $program_name cannot be used without a working tree.
      
      Catch these mistakes with
      
          $ git grep -n '[^_]gettext .*\\\$'
      
      and fix them all to use eval_gettext instead.
      
      Reported-by: Josh Bleecher Snyder
      Acked-by: 's avatarVasco Almeida <vascomalmeida@sapo.pt>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      acefe2be
  3. 30 Oct, 2016 1 commit
    • Anders Kaseorg's avatar
      git-sh-setup: be explicit where to dot-source git-sh-i18n from. · 1073094f
      Anders Kaseorg authored
      d323c6b6 ("i18n: git-sh-setup.sh: mark strings for translation",
      2016-06-17) started to dot-source git-sh-i18n shell script library,
      assuming that $PATH is already adjusted for our scripts, namely,
      $GIT_EXEC_PATH is at the beginning of $PATH.
      
      Old contrib scripts like contrib/convert-grafts-to-replace-refs.sh
      and contrib/rerere-train.sh and third-party scripts like guilt may
      however be using this as ". $(git --exec-path)/git-sh-setup",
      without satisfying that assumption.  Be more explicit by specifying
      its path prefixed with "$(git --exec-path)/". to be safe.
      
      While we’re here, move the sourcing of git-sh-i18n below the shell
      portability fixes.
      Signed-off-by: Anders Kaseorg's avatarAnders Kaseorg <andersk@mit.edu>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      1073094f
  4. 04 Aug, 2016 1 commit
  5. 19 Jun, 2016 1 commit
    • LE Manh Cuong's avatar
      sh-setup: enclose setting of ${VAR=default} in double-quotes · 01247e02
      LE Manh Cuong authored
      We often make sure an environment variable is set to
      something, either set by the user (in which case we do not
      molest it) or set it to our default value (otherwise), with
      
      	: ${VAR=default value}
      
      i.e. running the no-op command ":" with ${VAR} as its
      parameters (or the default value we supply), relying on that
      ":" is a no-op.
      
      This pattern, even though it is no-op from correctness point
      of view, still can be expensive if the existing value in VAR
      has shell glob (because they will be expanded against
      filesystem entities) and IFS whitespaces (because the value
      need to be split into multiple parameters).  Our invocation
      of ":" command does not care if the parameter given to it is
      after the value in VAR goes through these processing.
      
      Enclosing the whole thing in double-quote, i.e.
      
      	: "${VAR=default value}"
      
      avoids paying the unnecessary cost, so let's do so.
      Signed-off-by: LE Manh Cuong's avatarLE Manh Cuong <cuong.manhle.vn@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      01247e02
  6. 17 Jun, 2016 1 commit
  7. 10 Mar, 2016 1 commit
    • Junio C Hamano's avatar
      sane_grep: pass "-a" if grep accepts it · 71b40103
      Junio C Hamano authored
      Newer versions of GNU grep is reported to be pickier when we feed a
      non-ASCII input and break some Porcelain scripts.  As we know we do
      not feed random binary file to our own sane_grep wrapper, allow us
      to always pass "-a" by setting SANE_TEXT_GREP=-a Makefile variable
      to work it around.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      71b40103
  8. 01 Dec, 2014 1 commit
  9. 25 Nov, 2014 1 commit
  10. 15 Oct, 2014 1 commit
  11. 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: 's avatarMatthieu Moy <Matthieu.Moy@imag.fr>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      b3275838
  12. 03 Feb, 2014 1 commit
  13. 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: 's avatarOlaf Meeuwissen <olaf.meeuwissen@avasys.jp>
      Signed-off-by: 's avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      e54c1f2d
  14. 26 Nov, 2013 1 commit
    • Jonathan Nieder's avatar
      remove #!interpreter line from shell libraries · 11d62145
      Jonathan Nieder authored
      In a shell snippet meant to be sourced by other shell scripts, an
      opening #! line does more harm than good.
      
      The harm:
      
       - When the shell library is sourced, the interpreter and options from
         the #! line are not used.  Specifying a particular shell can
         confuse the reader into thinking it is safe for the shell library
         to rely on idiosyncrasies of that shell.
      
       - Using #! instead of a plain comment drops a helpful visual clue
         that this is a shell library and not a self-contained script.
      
       - Tools such as lintian can use a #! line to tell when an
         installation script has failed by forgetting to set a script
         executable.  This check does not work if shell libraries also start
         with a #! line.
      
      The good:
      
       - Text editors notice the #! line and use it for syntax highlighting
         if you try to edit the installed scripts (without ".sh" suffix) in
         place.
      
      The use of the #! for file type detection is not needed because Git's
      shell libraries are meant to be edited in source form (with ".sh"
      suffix).  Replace the opening #! lines with comments.
      
      This involves tweaking the test harness's valgrind support to find
      shell libraries by looking for "# " in the first line instead of "#!"
      (see v1.7.6-rc3~7, 2011-06-17).
      
      Suggested by Russ Allbery through lintian.  Thanks to Jeff King and
      Clemens Buchacher for further analysis.
      
      Tested by searching for non-executable scripts with #! line:
      
      	find . -name .git -prune -o -type f -not -executable |
      	while read file
      	do
      		read line <"$file"
      		case $line in
      		'#!'*)
      			echo "$file"
      			;;
      		esac
      	done
      
      The only remaining scripts found are templates for shell scripts
      (unimplemented.sh, wrap-for-bin.sh) and sample input used in tests
      (t/t4034/perl/{pre,post}).
      Signed-off-by: 's avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      11d62145
  15. 07 Aug, 2013 1 commit
  16. 19 Jun, 2013 1 commit
    • Junio C Hamano's avatar
      setup_reflog_action: document the rules for using GIT_REFLOG_ACTION · c3e2d189
      Junio C Hamano authored
      The set_reflog_action helper (in git-sh-setup) is designed to be
      used once at the very top of a program, like this in "git am", for
      example:
      
      	set_reflog_action am
      
      The helper function sets the given string to GIT_REFLOG_ACTION only
      when GIT_REFLOG_ACTION is not yet set.  Thanks to this, "git am",
      when run as the top-level program, will use "am" in GIT_REFLOG_ACTION
      and the reflog entries made by whatever it does will record the
      updates of refs done by "am".
      
      Because of the conditional assignment, when "git am" is run as a
      subprogram (i.e. an implementation detail) of "git rebase" that
      already sets GIT_REFLOG_ACTION to its own name, the call in "git am"
      to the helper function at the beginning will *not* have any effect.
      
      So "git rebase" can do this:
      
      	set_reflog_action rebase
      	... do its own preparation, like checking out "onto" commit
              ... decide to do "format-patch" to "am" pipeline
              	git format-patch --stdout >mbox
      		git am mbox
      
      and the reflog entries made inside "git am" invocation will say
      "rebase", not "am".
      
      Calls to "git" commands that update refs would use GIT_REFLOG_ACTION
      to record who did that update.  Most such calls in scripted Porcelains
      do not define custom reflog message and rely on GIT_REFLOG_ACTION to
      contain its (or its caller's, when it is called as a subprogram) name.
      
      If a scripted Porcelain wants to record a custom reflog message for
      a single invocation of "git" command (e.g. when "git rebase" uses
      "git checkout" to detach HEAD at the commit a series is to be
      replayed on), it needs to set GIT_REFLOG_ACTION to the custom
      message and export it while calling the "git" command, but such an
      assignment must be restricted to that single "git" invocation and
      should not be left behind to affect later codepath.
      
      Document the rules to avoid future confusion.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      c3e2d189
  17. 14 Jun, 2013 1 commit
  18. 13 Mar, 2013 1 commit
    • Kevin Bracey's avatar
      mergetools/p4merge: create a base if none available · 4549162e
      Kevin Bracey authored
      Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
      
         p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
      
      Commit 0a0ec7bd changed this to:
      
         p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"
      
      to avoid the problem of being unable to save in some circumstances with
      similar inputs.
      
      Unfortunately this approach produces much worse results on differing
      inputs. P4Merge really regards the blank file as the base, and once you
      have just a couple of differences between the two branches you end up
      with one a massive full-file conflict. The 3-way diff is not readable,
      and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a
      useful view.
      
      The original approach appears to have invoked special 2-way merge
      behaviour in P4Merge that occurs only if the base filename is "" or
      equal to the left input.  You get a good visual comparison, and it does
      not auto-resolve differences. (Normally if one branch matched the base,
      it would autoresolve to the other branch).
      
      But there appears to be no way of getting this 2-way behaviour and being
      able to reliably save. Having base==left appears to be triggering other
      assumptions. There are tricks the user can use to force the save icon
      on, but it's not intuitive.
      
      So we now follow a suggestion given in the original patch's discussion:
      generate a virtual base, consisting of the lines common to the two
      branches. This is the same as the technique used in resolve and octopus
      merges, so we relocate that code to a shared function.
      
      Note that if there are no differences at the same location, this
      technique can lead to automatic resolution without conflict, combining
      everything from the 2 files.  As with the other merges using this
      technique, we assume the user will inspect the result before saving.
      Signed-off-by: 's avatarKevin Bracey <kevin@bracey.fi>
      Reviewed-by: David Aguilar's avatarDavid Aguilar <davvid@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      4549162e
  19. 24 Feb, 2013 1 commit
  20. 10 Dec, 2012 1 commit
    • Junio C Hamano's avatar
      sh-setup: work around "unset IFS" bug in some shells · 393050c3
      Junio C Hamano authored
      With an unset IFS, field splitting is supposed to act as if IFS is
      set to the usual SP HT LF, but Marc Branchaud reports that the shell
      on FreeBSD 7.2 gets this wrong.
      
      It is easy to set it to the default value manually, and it is also
      safer in case somebody tries to save the old value away and restore,
      e.g.
      
      	$oIFS=$IFS
      	IFS=something
      	...
      	IFS=$oIFS
      
      while forgetting that the original IFS might be unset (which can be
      coded but would be more involved).
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      393050c3
  21. 18 Oct, 2012 1 commit
    • Jeff King's avatar
      git-sh-setup: refactor ident-parsing functions · ce80ca56
      Jeff King authored
      The only ident-parsing function we currently provide is
      get_author_ident_from_commit. This is not very
      flexible for two reasons:
      
        1. It takes a commit as an argument, and can't read from
           commit headers saved on disk.
      
        2. It will only parse authors, not committers.
      
      This patch provides a more flexible interface which will
      parse multiple idents from a commit provide on stdin. We can
      easily use it as a building block for the current function
      to retain compatibility.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      ce80ca56
  22. 08 Aug, 2012 1 commit
    • Junio C Hamano's avatar
      sh-setup: protect from exported IFS · 785063e0
      Junio C Hamano authored
      Many scripted Porcelains rely on being able to split words at the
      default $IFS characters, i.e. SP, HT and LF.  If the user exports a
      non-default IFS to the environment, what they read from plumbing
      commands such as ls-files that use HT to delimit fields may not be
      split in the way we expect.
      
      Protect outselves by resetting it, just like we do so against CDPATH
      exported to the environment.
      
      Noticed by Andrew Dranse <adranse@oanda.com>.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      785063e0
  23. 16 May, 2012 1 commit
    • Junio C Hamano's avatar
      git-sh-setup: define workaround wrappers before they are used · 10587ce6
      Junio C Hamano authored
      Recently we tweaked this scriptlet to let mingw port redefine "pwd" to
      always return Windows-style path, but the code to do so came after the
      first use of "pwd" to set up $GIT_DIR shell variable.
      
      Move the block to define these workaround wrappers, so that everything
      everything that executes when the scriptlet is dot-sourced uses the
      replacements.
      
      Noticed-by: Ramsay Jones
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      10587ce6
  24. 18 Apr, 2012 1 commit
  25. 04 Feb, 2012 1 commit
    • Junio C Hamano's avatar
      parse_date(): '@' prefix forces git-timestamp · 2c733fb2
      Junio C Hamano authored
      The only place that the issue this series addresses was observed
      where we read "cat-file commit" output and put it in GIT_AUTHOR_DATE
      in order to replay a commit with an ancient timestamp.
      
      With the previous patch alone, "git commit --date='20100917 +0900'"
      can be misinterpreted to mean an ancient timestamp, not September in
      year 2010.  Guard this codepath by requring an extra '@' in front of
      the raw git timestamp on the parsing side. This of course needs to
      be compensated by updating get_author_ident_from_commit and the code
      for "git commit --amend" to prepend '@' to the string read from the
      existing commit in the GIT_AUTHOR_DATE environment variable.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      2c733fb2
  26. 05 Oct, 2011 1 commit
  27. 13 Jun, 2011 1 commit
  28. 24 May, 2011 1 commit
    • Junio C Hamano's avatar
      require-work-tree wants more than what its name says · e2eb5273
      Junio C Hamano authored
      Somebody tried "git pull" from a random place completely outside the work
      tree, while exporting GIT_DIR and GIT_WORK_TREE that are set to correct
      places, e.g.
      
          GIT_WORK_TREE=$HOME/git.git
          GIT_DIR=$GIT_WORK_TREE/.git
          export GIT_WORK_TREE GIT_DIR
          cd /tmp
          git pull
      
      At the beginning of git-pull, we check "require-work-tree" and then
      "cd-to-toplevel".  I _think_ the original intention when I wrote the
      command was "we MUST have a work tree, our $(cwd) might not be at the
      top-level directory of it", and no stronger than that.  That check is a
      very sensible thing to do before doing cd-to-toplevel.  We check that the
      place we would want to go exists, and then go there.
      
      But the implementation of require_work_tree we have today is quite
      different.  I don't have energy to dig the history, but currently it says:
      
          test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true ||
          die "fatal: $0 cannot be used without a working tree."
      
      Which is completely bogus.  Even though we may happen to be just outside
      of it right now, we may have a working tree that we can cd_to_toplevel
      back to.
      
      Add a function "require_work_tree_exists" that implements the check
      this function originally intended (this is so that third-party scripts
      that rely on the current behaviour do not have to get broken).
      
      For now, update _no_ in-tree scripts, not even "git pull", as nobody on
      the list seems to really care about the above corner case workflow that
      triggered this. Scripts can be updated after vetting that they do want the
      "we want to make sure the place we are going to go actually exists"
      semantics.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      e2eb5273
  29. 28 Oct, 2010 1 commit
  30. 03 Oct, 2010 1 commit
  31. 27 Sep, 2010 1 commit
  32. 25 Feb, 2010 1 commit
  33. 17 Feb, 2010 1 commit
  34. 15 Feb, 2010 1 commit
    • Jonathan Nieder's avatar
      am: Fix launching of pager · f6dff119
      Jonathan Nieder authored
      The pagination functionality in git am has some problems:
      
       - It does not check if stdout is a tty, so it always paginates.
      
       - If $GIT_PAGER uses any environment variables, they are being
         ignored, since it does not run $GIT_PAGER through eval.
      
       - If $GIT_PAGER is set to the empty string, instead of passing
         output through to stdout, it tries to run $dotest/patch.
      
      Fix them.  While at it, move the definition of git_pager() to
      git-sh-setup so authors of other commands are not tempted to
      reimplement it with the same mistakes.
      Signed-off-by: 's avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      f6dff119
  35. 31 Jan, 2010 1 commit
  36. 12 Jan, 2010 1 commit
  37. 24 Nov, 2009 1 commit
    • Junio C Hamano's avatar
      Protect scripted Porcelains from GREP_OPTIONS insanity · e1622bfc
      Junio C Hamano authored
      If the user has exported the GREP_OPTIONS environment variable, the output
      from "grep" and "egrep" in scripted Porcelains may be different from what
      they expect.  For example, we may want to count number of matching lines,
      by "grep" piped to "wc -l", and GREP_OPTIONS=-C3 will break such use.
      
      The approach taken by this change to address this issue is to protect only
      our own use of grep/egrep.  Because we do not unset it at the beginning of
      our scripts, hook scripts run from the scripted Porcelains are exposed to
      the same insanity this environment variable causes when grep/egrep is used
      to implement logic (e.g. "grep | wc -l"), and it is entirely up to the
      hook scripts to protect themselves.
      
      On the other hand, applypatch-msg hook may want to show offending words in
      the proposed commit log message using grep to the end user, and the user
      might want to set GREP_OPTIONS=--color to paint the match more visibly.
      The approach to protect only our own use without unsetting the environment
      variable globally will allow this use case.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      e1622bfc
  38. 13 Nov, 2009 1 commit
  39. 18 Jun, 2009 1 commit
  40. 10 Jun, 2009 1 commit
    • Junio C Hamano's avatar
      Makefile: insert SANE_TOOL_PATH to PATH before /bin or /usr/bin · 61dbb3c4
      Junio C Hamano authored
      In an earlier patch, we introduced SANE_TOOL_PATH that is prepended to
      user's PATH.  This had an unintended consequence of overriding user's
      private binary directory that typically comes earlier in the PATH to holds
      even saner commands than whatever comes with the system.
      
      For example, a user may have ~/bin that is early in the path and contains
      a shell script "vi" that launches system's /bin/vi with specific options.
      Prepending SANE_TOOL_PATH to the PATH that happens to have "vi" in it
      defeats such customization.
      
      This fixes the issue by inserting SANE_TOOL_PATH just before /bin or
      /usr/bin appears on the PATH.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      61dbb3c4