1. 04 Apr, 2019 1 commit
  2. 05 Apr, 2018 1 commit
  3. 19 Jun, 2017 1 commit
  4. 12 Dec, 2016 1 commit
  5. 29 Nov, 2016 2 commits
    • David Aguilar's avatar
      mergetools/vimdiff: trust Vim's exit code · 29672844
      David Aguilar authored
      Allow vimdiff users to signal that they do not want to use the
      result of a merge by exiting with ":cquit", which tells Vim to
      exit with an error code.
      
      This is better than the current behavior because it allows users
      to directly flag that the merge is bad, using a standard Vim
      feature, rather than relying on a timestamp heuristic that is
      unforgiving to users that save in-progress merge files.
      
      The original behavior can be restored by configuring
      mergetool.vimdiff.trustExitCode to false.
      Reported-by: Dun Peal's avatarDun Peal <dunpealer@gmail.com>
      Signed-off-by: David Aguilar's avatarDavid Aguilar <davvid@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      29672844
    • 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: 's avatarJunio C Hamano <gitster@pobox.com>
      7c10605d
  6. 04 Apr, 2016 2 commits
  7. 12 Feb, 2016 1 commit
  8. 20 May, 2015 1 commit
  9. 21 Nov, 2014 1 commit
  10. 21 Oct, 2014 1 commit
  11. 16 Oct, 2014 1 commit
  12. 22 Apr, 2014 1 commit
  13. 13 Oct, 2013 1 commit
  14. 09 May, 2013 1 commit
  15. 13 Mar, 2013 2 commits
    • 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
    • Kevin Bracey's avatar
      mergetools/p4merge: swap LOCAL and REMOTE · c699a7cc
      Kevin Bracey authored
      Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
      the incoming branch is now in the left-hand, blue triangle pane, and the
      current branch is in the right-hand, green circle pane.
      
      This change makes use of P4Merge consistent with its built-in help, its
      reference documentation, and Perforce itself. But most importantly, it
      makes merge results clearer. P4Merge is not totally symmetrical between
      left and right; despite changing a few text labels from "theirs/ours" to
      "left/right" when invoked manually, it still retains its original
      Perforce "theirs/ours" viewpoint.
      
      Most obviously, in the result pane P4Merge shows changes that are common
      to both branches in green. This is on the basis of the current branch
      being green, as it is when invoked from Perforce; it means that lines in
      the result are blue if and only if they are being changed by the merge,
      making the resulting diff clearer.
      
      Note that P4Merge now shows "ours" on the right for both diff and merge,
      unlike other diff/mergetools, which always have REMOTE on the right.
      But observe that REMOTE is the working tree (ie "ours") for a diff,
      while it's another branch (ie "theirs") for a merge.
      
      Ours and theirs are reversed for a rebase - see "git help rebase".
      However, this does produce the desired "show the results of this commit"
      effect in P4Merge - changes that remain in the rebased commit (in your
      branch, but not in the new base) appear in blue; changes that do not
      appear in the rebased commit (from the new base, or common to both) are
      in green. If Perforce had rebase, they'd probably not swap ours/theirs,
      but make P4Merge show common changes in blue, picking out our changes in
      green. We can't do that, so this is next best.
      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>
      c699a7cc
  16. 10 Feb, 2013 1 commit
  17. 02 Feb, 2013 1 commit
  18. 29 Jan, 2013 1 commit
  19. 28 Jan, 2013 1 commit
  20. 27 Jan, 2013 1 commit
  21. 27 Dec, 2012 1 commit
  22. 11 Oct, 2012 1 commit
  23. 25 Sep, 2012 1 commit
  24. 10 Aug, 2012 1 commit
  25. 05 Mar, 2012 1 commit
  26. 10 Feb, 2012 1 commit
    • Jonathan Nieder's avatar
      mergetools/meld: Use --help output to detect --output support · 759a904e
      Jonathan Nieder authored
      In v1.7.7-rc0~3^2 (2011-08-19), git mergetool's "meld" support learned
      to use the --output option when calling versions of meld that are
      detected to support it (1.5.0 and newer, hopefully).
      
      Alas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as
      supporting the option, so on systems with such meld, instead of
      getting a nice merge helper, the operator gets a dialog box with the
      text "Wrong number of arguments (Got 5)".  (Version 1.1.5 is when meld
      switched to using optparse.  One consequence of that change was that
      errors in usage are detected and signalled through the exit status
      even when --help was passed.)
      
      Luckily there is a simpler check that is more reliable: the usage
      string printed by "meld --help" reliably reflects whether --output is
      supported in a given version.  Use it.
      Reported-by: 's avatarJeff Epler <jepler@unpythonic.net>
      Signed-off-by: 's avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      759a904e
  27. 16 Oct, 2011 1 commit
  28. 19 Aug, 2011 2 commits