user/sven/git.git/mergetools, branch v1.8.3.3

Sync with v1.8.2.3

2013-05-09T20:32:54Z

* maint: Git 1.8.2.3 t5004: avoid using tar for checking emptiness of archive t5004: ignore pax global header file mergetools/kdiff3: do not use --auto when diffing transport-helper: trivial style cleanup

mergetools/kdiff3: do not use --auto when diffing

2013-05-09T18:59:39Z

The `kdiff3 --auto` help message is, "No GUI if all conflicts are auto- solvable." This flag was carried over from the original mergetool commands. diff_cmd() is for two-way comparisons only so remove the superfluous flag. Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

mergetools/p4merge: create a base if none available

2013-03-13T17:46:07Z

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: Kevin Bracey Reviewed-by: David Aguilar Signed-off-by: Junio C Hamano

mergetools/p4merge: swap LOCAL and REMOTE

2013-03-13T17:45:56Z

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: Kevin Bracey Reviewed-by: David Aguilar Signed-off-by: Junio C Hamano

Merge branch 'da/p4merge-mktemp-fix'

2013-02-15T00:05:56Z

* da/p4merge-mktemp-fix: p4merge: fix printf usage

p4merge: fix printf usage

2013-02-10T19:40:52Z

Do not use a random string as if it is a format string for printf when showing it literally; instead feed it to '%s' format. Reported-by: Asheesh Laroia Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

Merge branch 'ss/mergetools-tortoise'

2013-02-07T22:42:01Z

Update mergetools to work better with newer merge helper tortoise ships. * ss/mergetools-tortoise: mergetools: teach tortoisemerge to handle filenames with SP correctly mergetools: support TortoiseGitMerge

Merge branch 'jk/mergetool'

2013-02-07T22:41:57Z

Cleans up mergetool/difftool combo. * jk/mergetool: mergetools: simplify how we handle "vim" and "defaults" mergetool--lib: don't call "exit" in setup_tool mergetool--lib: improve show_tool_help() output mergetools/vim: remove redundant diff command git-difftool: use git-mergetool--lib for "--tool-help" git-mergetool: don't hardcode 'mergetool' in show_tool_help git-mergetool: remove redundant assignment git-mergetool: move show_tool_help to mergetool--lib

mergetools: teach tortoisemerge to handle filenames with SP correctly

2013-02-02T02:06:03Z

TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths with spaces in them by using -option "$FILE" (not -option:"$FILE", which does not work for such paths) syntax. This change was necessary because of MSYS path mangling [1], the ":" after the "base" etc. arguments to TortoiseMerge caused the whole argument instead of just the file name to be quoted in case of file names with spaces. So TortoiseMerge was passed "-base:new file.txt" instead of -base:"new file.txt" (including the quotes). To work around this, TortoiseGitMerge does not require the ":" after the arguments anymore which fixes handling file names with spaces [2] (as written above). [1] http://www.mingw.org/wiki/Posix_path_conversion [2] https://github.com/msysgit/msysgit/issues/57 Signed-off-by: Sven Strickroth Reported-by: Sebastian Schuberth Signed-off-by: Junio C Hamano

mergetools: simplify how we handle "vim" and "defaults"

2013-01-29T03:00:38Z

Remove the exceptions for "vim" and "defaults" in the mergetool library so that every filename in mergetools/ matches 1:1 with the name of a valid built-in tool. Define the trivial fallback definition of shell functions in-line in git-mergetool-lib script, instead of dot-sourcing them from another file. The result is much easier to follow. [jc: squashed in an update from John Keeping as well] Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano