Of course, nobody in their right mind would compare anything with /dev/null, but when diffmerge is integrated into source control system, sometimes (often) situation arrives when diffmerge is executed for a new file that have no prior versions. In that case git is passing /dev/null instead of file name.

For some peculiar reasons /dev/null works fine if entered into UI (seing it as empty file - great), but fails with the error "File (/dev/null) not found", if executed from command line with /dev/null as one of the parameters.

It would be nice to have that inconsistency corrected.

P.S. this was tested with the DiffMerge 3.1.0 (1002) for Mac OS X on Leopard.

Thanks for the report on that. I'll get this logged.

How odd!

I tracked this down. The command line parser code has to stat() all
of the pathnames given on the command line and check the type. This
is so that it can determine if it was given files or directories (or an
invalid combination of both). since /dev/null is a character-special-file
rather than a regular file, it falls out of this screening as an invalid
file.

i've logged this.

in the mean time, as a workaround, you might update the diffmerge.sh
script to check for /dev/null and substitute an empty temp file. i know
this is a pain, but it'll let you make progress.

sorry,
jeff

PS. let me know how your git integration goes and if i can do anything
else to help.

What you recommend, Jeff, is precisely what I ended up doing yesterday

Here is my script:

Code: Select all

#!/bin/sh

# Author: Olek Poplavsky
# Script name: diffmerge-git-wrapper
# This script works as interface bridge between git and DiffMerge and allows to get nice visual
# diffs from git; right now script requires empty file diffmerge-git-wrapper-empty-file in the same
# directory as script
# easiest way to integrate it with git is by setting environment variable "export GIT_EXTERNAL_DIFF='diffmerge-git-wrapper'"

left_path=$2
right_path=$5


basedir=`dirname $0`

# working around bug in diffmerge, it does not like /dev/null yet as of 3.1.0
if [[ "$left_path" = "/dev/null" ]]
then
  left_path="$basedir/diffmerge-git-wrapper-empty-file"
fi

if [[ "$right_path" = "/dev/null" ]]
then
  right_path="$basedir/diffmerge-git-wrapper-empty-file"
fi

left_title="$1 $3"
right_title="$1 $6"

diffmerge $left_path $right_path --title1="$left_title" --title2="$right_title"

jeffhostetler wrote:PS. let me know how your git integration goes and if i can do anything
else to help.

Jeff, how difficult is it going to be to add feature that is similar to what tkdiff does with "tkdiff -conflict filename"?
The fact is, git does not have any hooks that would allow to execute diffmerge when conflict is found, like it can be done in subversion.
The best way to resolve conflicts would be AFTER merge have happened, using file with merged changes using 'CVS conflict merge' format, with <<<<, >>>> and ==== markup.
Some tools, like tkdiff and guiffy do that, can diffmerge do it too?

No, it doesn't currently support CVS style conflict markers.

Our intended usage (with Vault/Fortress) was that we try
the automatic merge (internally within Vault/Fortress) in
the background and if there was a conflict, mark the files
as 'needs merge' and let the user raise DiffMerge at their
convenience to deal with it. Once the user quits DiffMerge,
they get asked by Vault/Fortress if everything is resolved
or not.

I've not played with git, so excuse me for a moment if I seem
dense. So if I understand what you're asking, you want git to
do the merge as usual (using something like diff3) which either
works OK and produces a single file -or- which has conflicts and
produces a single file with CVS style conflict markers. Then you
want to run DiffMerge on the single file and see the file split into
3 panels (as usual) and the conflicts highlighted (and the CVS
markers removed). Right??

I suppose we could add CVS style markers, but that would
be a bit of work. But I will log a feature request for it. This
would be quite useful.

BTW I don't know if you saw it or not, but I found a section on
"Defining a custom merge driver" in
http://www.kernel.org/pub/software/scm/ ... butes.html
which seems to imply that you could replace the merge driver
with DiffMerge and avoid the CVS marker stuff. But I haven't
tried this (as I said, I haven't played with GIT). This might raise
it in for all files, when you wouldn't want that. But if that is the case
you could bind it to a shell script that tries the diff3 first and if it exits
with conflict status throw away that result and launch DiffMerge
on the original 3 files.


hope this helps,
jeff

Thank you for the reference, Jeff.

This might be a way to go for some people, but I would prefer the workflow where I can manually merge conflicted changes AFTER merging branches, not in the process.
That would allow, for example to see that merging produces too many conflicts and scrap it altogether, instead of being forced to blindly go through one manual conflict resolution to another without knowing how many are still ahead.

Anyway, I found that almost perfect solution for me exists in git itself.
It is called git-mergetool.
This helper script will execute external merge tool for every file that is marked as "merged with conflict".

http://www.kernel.org/pub/software/scm/ ... etool.html

The only downside is that diffmerge is not in the list of the tools that it supports.
I currently modified it to include support for the diffmerge, it seems to work very well for me, and after couple weeks of use/testing I plan on posting my changes here and maybe attempting to get them accepted by git team.

Yes, please post back when you get things working.

jeff