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

Kirill· Apr 13, 2025, 14:07 UTC · lore

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]

K Jayatheerth· Apr 13, 2025, 15:11 UTC · re: Kirill · lore

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

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.

Show 18 quoted lines

> 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.

Show 10 quoted lines

> 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.

Show 5 quoted lines

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

-- -Jayatheerth