p4merge does not properly handle the case where "/dev/null"
is passed as a filename.
Workaround it by creating a temporary file for this purpose.
Reported-by: Jeremy Morton <redacted>
Signed-off-by: David Aguilar <redacted>
---
Jeremy, can you test this?
mergetools/p4merge | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 1a45c1b..295361a 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -1,5 +1,30 @@
diff_cmd () {
+ # p4merge does not like /dev/null
+ rm_local=
+ rm_remote=
+ if test "/dev/null" = "$LOCAL"
+ then
+ LOCAL="./p4merge-dev-null.LOCAL.$$"
+ >"$LOCAL"
+ rm_local=true
+ fi
+ if test "/dev/null" = "$REMOTE"
+ then
+ REMOTE="./p4merge-dev-null.REMOTE.$$"
+ >"$REMOTE"
+ rm_remote=true
+ fi
+
"$merge_tool_path" "$LOCAL" "$REMOTE"
+
+ if test -n "$rm_local"
+ then
+ rm -f "$LOCAL"
+ fi
+ if test -n "$rm_remote"
+ then
+ rm -f "$REMOTE"
+ fi
}
merge_cmd () {--
1.8.0.rc1
Sorry to be replying to this so late; I hadn't noticed the post until now!
I've tried putting that code in my p4merge script and yes it does indeed
work fine. However, it puts a temporary file in the working directory
which I'm not sure is a good idea? If we look at this patch which
actually solved pretty much the same problem, but when merging and,
during a merge conflict, a file was created in both branches:
https://github.com/git/git/commit/ec245ba
... it is creating a temp file in a proper temp dir, rather than in the
working dir. I think that would be the proper solution here. However,
I really want to get this fixed so I'd be happy for this band-aid fix of
the p4merge script to be checked in until we could get a patch more like
the aforementioned one, at a later date, to create empty files in a
proper temp dir and pass them as $LOCAL and $REMOTE. :-)
--
Best regards,
Jeremy Morton (Jez)
On 11/10/2012 04:22, David Aguilar wrote:
quoted hunk
p4merge does not properly handle the case where "/dev/null"
is passed as a filename.
Workaround it by creating a temporary file for this purpose.
Reported-by: Jeremy Morton<redacted>
Signed-off-by: David Aguilar<redacted>
---
Jeremy, can you test this?
mergetools/p4merge | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 1a45c1b..295361a 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -1,5 +1,30 @@
diff_cmd () {
+ # p4merge does not like /dev/null
+ rm_local=
+ rm_remote=
+ if test "/dev/null" = "$LOCAL"
+ then
+ LOCAL="./p4merge-dev-null.LOCAL.$$"
+ >"$LOCAL"
+ rm_local=true
+ fi
+ if test "/dev/null" = "$REMOTE"
+ then
+ REMOTE="./p4merge-dev-null.REMOTE.$$"
+ >"$REMOTE"
+ rm_remote=true
+ fi
+
"$merge_tool_path" "$LOCAL" "$REMOTE"
+
+ if test -n "$rm_local"
+ then
+ rm -f "$LOCAL"
+ fi
+ if test -n "$rm_remote"
+ then
+ rm -f "$REMOTE"
+ fi
}
merge_cmd () {
On Sat, Oct 27, 2012 at 1:47 AM, Jeremy Morton [off-list ref] wrote:
Sorry to be replying to this so late; I hadn't noticed the post until now!
I've tried putting that code in my p4merge script and yes it does indeed
work fine. However, it puts a temporary file in the working directory which
I'm not sure is a good idea? If we look at this patch which actually solved
pretty much the same problem, but when merging and, during a merge conflict,
a file was created in both branches:
https://github.com/git/git/commit/ec245ba
... it is creating a temp file in a proper temp dir, rather than in the
working dir. I think that would be the proper solution here. However, I
really want to get this fixed so I'd be happy for this band-aid fix of the
p4merge script to be checked in until we could get a patch more like the
aforementioned one, at a later date, to create empty files in a proper temp
dir and pass them as $LOCAL and $REMOTE. :-)
I had the same thoughts when I wrote it, but I figured that following
the existing pattern used by mergetool for $REMOTE and $LOCAL when
they do exist was simpler as the first step.
I have a patch that fixes this by using mktemp that I will send shortly.
It only does it for the /dev/null file since the existing behavior for
files that do exist is fine.
--
David