1. 29 Nov, 2016 1 commit
    • David Aguilar's avatar
      mergetool: honor mergetool.$tool.trustExitCode for built-in tools · 7c10605d
      David Aguilar authored
      Built-in merge tools contain a hard-coded assumption about
      whether or not a tool's exit code can be trusted to determine
      the success or failure of a merge.  Tools whose exit codes are
      not trusted contain calls to check_unchanged() in their
      merge_cmd() functions.
      A problem with this is that the trustExitCode configuration is
      not honored for built-in tools.
      Teach built-in tools to honor the trustExitCode configuration.
      Extend run_merge_cmd() so that it is responsible for calling
      check_unchanged() when a tool's exit code cannot be trusted.
      Remove check_unchanged() calls from scriptlets since they are no
      longer responsible for calling it.
      When no configuration is present, exit_code_trustable() is
      checked to see whether the exit code should be trusted.
      The default implementation returns false.
      Tools whose exit codes can be trusted override
      exit_code_trustable() to true.
      Reported-by: Dun Peal's avatarDun Peal <dunpealer@gmail.com>
      Signed-off-by: David Aguilar's avatarDavid Aguilar <davvid@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  2. 25 Apr, 2016 1 commit
  3. 04 Apr, 2016 1 commit
  4. 19 Jun, 2015 1 commit
    • Michael J Gruber's avatar
      mergetool-lib: fix default tool selection · f67986b9
      Michael J Gruber authored
      When no diff nor merge tool is specified (config, option), mergetool-lib
      is supposed to choose a default tool from a set of tools. That set is
      constructed dynamically depending on the environment (graphical, editor
      setting) as a space separated string of tool names.
      719518f5 (mergetool--lib: set IFS for difftool and mergetool, 2015-05-20)
      introduced a newline as IFS which breaks the parsing of the space
      separated list into items, resulting in a failed search for an available
      Set IFS to a space locally for the tool search.
      Signed-off-by: default avatarMichael J Gruber <git@drmicha.warpmail.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  5. 20 May, 2015 1 commit
  6. 21 Nov, 2014 2 commits
  7. 14 Nov, 2014 1 commit
  8. 21 Oct, 2014 1 commit
  9. 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
      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
      		read line <"$file"
      		case $line in
      			echo "$file"
      The only remaining scripts found are templates for shell scripts
      (unimplemented.sh, wrap-for-bin.sh) and sample input used in tests
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  10. 14 Oct, 2013 1 commit
  11. 13 Oct, 2013 1 commit
  12. 29 Jul, 2013 1 commit
  13. 17 Jun, 2013 1 commit
  14. 03 Feb, 2013 3 commits
  15. 29 Jan, 2013 3 commits
  16. 28 Jan, 2013 2 commits
  17. 25 Jan, 2013 3 commits
  18. 25 Sep, 2012 1 commit
  19. 10 Aug, 2012 1 commit
  20. 23 Jul, 2012 1 commit
    • Junio C Hamano's avatar
      mergetool: support --tool-help option like difftool does · 109859e2
      Junio C Hamano authored
      This way we do not have to risk the list of tools going out of sync
      between the implementation and the documentation.
      In the same spirit as bf73fc21 (difftool: print list of valid tools
      with '--tool-help', 2012-03-29), trim the list of merge backends in
      the documentation.  We do not want to have a complete list of valid
      tools; we only want a list to help people guess what kind of things
      the tools do to be specified there, and refer them to --tool-help
      for a complete list.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  21. 20 Sep, 2011 1 commit
  22. 19 Aug, 2011 2 commits
  23. 05 Aug, 2011 1 commit
  24. 26 May, 2011 1 commit
  25. 01 May, 2011 1 commit
    • Ciaran Jessup's avatar
      Pass empty file to p4merge where no base is suitable. · 0a0ec7bd
      Ciaran Jessup authored
      Modify the p4merge client command to pass a reference to an empty file
      instead of the local file when no base revision available.
      In the situation where a merge tries to add a file from one branch
      into a branch that already contains that file (by name), p4merge
      currently seems to have successfully automatically resolved the
      'conflict' when it is opened (correctly if the files differed by
      just whitespace for example) but leaves the save button disabled. This
      means the user of the p4merge client cannot commit the resolved
      changes back to disk and merely exits, leaving the original
      (merge-conflicted) file intact on the disk.
      Provide an empty base file to p4merge so that it leaves the save
      button enabled.  This will allow saving of the auto-resolution to
      Signed-off-by: default avatarCiaran Jessup <ciaranj@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  26. 28 Feb, 2011 2 commits
  27. 25 Feb, 2011 1 commit
  28. 29 Sep, 2010 1 commit
  29. 15 Sep, 2010 2 commits