From: Jayatheerth <jayatheerthkulkarni2005@xxxxxxxxx> // <-- 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
