So the latest update to Git For Windows broke my previous method using LVCompare for viewing diffs. Everything was working. Then I updated Git For Windows and everything stopped working and I got the error message shown above.
Previously when using
git difftool command, Git would check out the files into a temp directory and give them different names. It would then pass those relative paths to whatever you defined as the difftool. Now with LVCompare you had to have a wrapper in order to change the paths from Unix to Windows style and make them absolute, before calling LVCompare. There were various solutions out there written in different languages - mostly bash or LabVIEW itself. I personally had a bash script that did the heavy lifting for me. I figured a bash script beat having to build a LabVIEW executable. Complicated, but it all worked.
The problem came when the Git developers decided that it would be nice to compare and diff folder hierarchies. I'm not sure I was missing that ability, but I'm sure there is some legitimate use case. To do this, they wanted everything to have the same names but be in different folders. So now,
git difftool produces paths to 2 files in different folders but with the same file name. That's great, except that LVCompare requires the 2 files to have different names, hence the error message I was getting.
The solution is simple actually (at least in theory - it did require a little bash knowledge in order to get it to work). I simply added code to check if the filenames are the same and prepend remote to the remote filename. Crude, but it works.
Here's the previous version. The
abspath function is a function I wrote that converts a relative linux path to an absolute windows path. You can see in the original all I'm doing is massaging the paths and we're directly passing the arguments to the script.
#Previous version # Convert each git-relative path to an absolute Windows-style path localWin=$(abspath "$2") remoteWin=$(abspath "$1") echo Launching "$lvcompare" exec "$lvcompare" "$localWin" "$remoteWin"
Here's the new code. I created some new variables
remoteOrig to hold the original linux relative paths. The
if statement checks to see if the 2 filenames are identical. If so, then it creates a
remoteNewPath and moves the original file to that path and then sets
remoteOrig to that new path. Then the rest is basically the same as above. I did add 2
echo statements to show the paths for debugging.
# New code # Convert each git-relative path to an absolute Windows-style path localOrig="$2" remoteOrig="$1" if [[ "$(basename "$localOrig") == "$(basename "$remoteOrig") ]] then remoteNewPath="$(dirname "$remoteOrig")""/""remote""$(basename "$remoteOrig")" mv "$remoteOrig" "$remoteNewPath" remoteOrig="$remoteNewPath" fi localWin=$(abspath "$localOrig") remoteWin=$(abspath "$remoteOrig") echo Launching "$lvcompare" echo local "$localWin" echo remote "$remoteWin" exec "$lvcompare" "$localWin" "$remoteWin"
While I was at it, I also made another update. I had originally hardcoded the path to LVCompare.exe. However depending on if you are using 32 or 64 bit LabVIEW, that path changes. I got tired of having to change that path manually, so now if the 64 bit version doesn't exist, I set it to the 32 bit path.
#old version # Path to executable, edit this if needed lvcompare="/c/Program Files (x86)/National Instruments/Shared/LabVIEW Compare/LVCompare.exe"
# new version # Path to executable, edit this if needed lvcompare="/c/Program Files/National Instruments/Shared/LabVIEW Compare/LVCompare.exe" if [[ ! -f "$lvcompare" ]] then lvcompare="/c/Program Files (x86)/National Instruments/Shared/LabVIEW Compare/LVCompare.exe" fi
git mergetool command appears to be unaffected by this change. However, I did similarly update the mergetool wrapper to account for the 32 vs 64 bit issue.
Get the latest
This is all available on GitLab. You can check it out here:
I Want a Wrapper Written in LabVIEW
If for some reason you don't want to use this bash solution, Stefan Lemmens pointed me to a version written in LabVIEW. That helped to point me in the right direction. I find the bash solution better because it's a script and it's easy to change/tweak (assuming you know a little bash). With Stefan's solution, it's all in LabVIEW, which may be a plus, but you have to build it into an executable. The bash solution just seems more lightweight.