Bug: git difftool --tool=meld -d HEAD^ lose copied file

Bug: git difftool --tool=meld -d HEAD^ lose copied file

[Kirill]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

mkdir git-copy-lost
cd git-copy-lost
git init
touch file
git add file
git commit -am "message"
git rm file
git commit -am "message"
git difftool --tool=meld -d HEAD^

In meld right click on `file` in left pane and press "Copy To Right" in menu
Quit meld

ls -l

What did you expect to happen? (Expected behavior)

`file` is present in working directory

What happened instead? (Actual behavior)

`file` is absent in working directory

What's different between what you expected and what actually happened?

`file` is missing while it was copied in meld with "Copy To Right" button

Anything else you want to add:

This bug was also reported for meld but I don't think meld can do
anything with it
because copied file is being lost in temporary directory like
/tmp/git-difftool.7bOf2n/right/ created by git
Meld bug: https://gitlab.gnome.org/GNOME/meld/-/issues/555

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.49.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
libcurl: 8.9.1
OpenSSL: OpenSSL 3.2.4 11 Feb 2025
zlib-ng: 2.2.3
uname: Linux 6.13.9-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Mar 29
01:29:31 UTC 2025 x86_64
compiler info: gnuc: 14.2
libc info: glibc: 2.40
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Re: Bug: git difftool --tool=meld -d HEAD^ lose copied file

[K Jayatheerth]

From: Jayatheerth <jayatheerthkulkarni2005@gmail.com> // <-- FIXED

On 2025-04-13 14:07 UTC, Kirill wrote:
> Hi Git developers,
>

Hey, Kirill
Thanks for the detailed report.

> I believe I've found unexpected behavior when using `git difftool -d`
> with an external tool like Meld, where actions within the tool do not
> affect the working directory as might be intuitively expected.
>
> [Steps to reproduce snipped]
>
> My understanding is that `git difftool -d` operates by checking out the
> compared tree-ishes into temporary directories (e.g., `/tmp/git-difftool.XXXX/left`
> representing `HEAD^` and `/tmp/git-difftool.XXXX/right` representing the
> working directory state).
>
> Meld performs the copy operation successfully *between these temporary directories*.
> The file exists in `/tmp/git-difftool.XXXX/right/file` before Meld exits.
>
> However, upon Meld's exit, Git cleans up by removing these temporary
> directories entirely. The copied file within the temporary 'right' directory
> is discarded, and the change is never propagated back to the actual
> working directory.

Yes, your understanding of the temporary directory creation, the successful
copy *within* those directories by Meld, and the subsequent cleanup
by Git discarding those changes is entirely correct. This is the
designed mechanism.

> While this might be the intended design (operating safely on temporary copies),
> it leads to counter-intuitive behavior and data loss (of the action performed
> in the difftool) for users expecting interactive modification capabilities
> similar to, perhaps, `git mergetool`.
>
> This behavior was also reported against Meld, but it seems unlikely Meld
> can address it, as the temporary directories and the cleanup process are
> managed by Git:
> Meld bug: https://gitlab.gnome.org/GNOME/meld/-/issues/555
>

However, you are absolutely right that this intended behavior is counter-intuitive for users interacting with graphical tools like Meld, where actions like "Copy to Right" or direct editing feel like they should have a persistent effect. It's a frequent point of confusion, as evidenced by the Meld issue you linked as well.

While changing this core behavior of `difftool -d` would be a significant design shift with potential safety implications, perhaps the most practical improvement would be to enhance the documentation. The `git-difftool(1)` man page could more explicitly warn users that when using `--dir-diff`, modifications made within the external tool to the temporary directories are *not* propagated back to the working directory.

For achieving the outcome you expected (restoring the file from the previous commit), the standard Git way remains using commands designed for working directory manipulation, such as:

`git restore --source=HEAD^ file`

or the older:

`git checkout HEAD^ -- file`

Thanks again for bringing this usability issue to the list's attention. Clearer documentation might help prevent future confusion.

>
> [System Info snipped]
>
> Thanks,
> Kirill

--
-Jayatheerth