open repo file instead of a tmp file to modify in git difftool

Question

git difftool --tool=vimdiff --no-prompt HEAD~1 HEAD

git will open vim with two temporary files on the left and right side. Is there a way to force open the repo file on the right so that I can modify it directly?

Answer 1

No: because you've selected two specific commits , there are no files to change .

That seems a little odd to say. It actually is a little odd, until you realize this thing about commits: while commits do contain files, ¹ the files they contain are frozen . None of them can ever be changed. They are committed , and the contents of any commit are as permanent as the commit itself, ² and totally read-only.

Of course, when you use Git, you have files that you can change. If you didn't, it would be hard to use Git. But those aren't the committed files: those are the work-tree copies. If you direct git difftool --tool=vimdiff to use those files as one side of the operation, it already does open those files directly. To do that:

git difftool --tool=vimdiff <options> <commit>

where <options> includes your --no-prompt and <commit> might be HEAD~1 again, for instance.

(As with git diff , git difftool can be told to compare two commits, or to compare one commit to the current work-tree. There is no option for comparing a commit to the current index contents. The rest of this answer does not mention the index, but the index holds a third copy of every file. Files inside commits are in a special, read-only, Git-only format. Files in your work-tree are in a useful format, so that you can read or edit them directly. Files in your index are in a halfway zone, between the HEAD commit where they're frozen and the work-tree where they're normal: the index copies are unfrozen, but still Git-only and compressed. Git makes new commits from the index copy, which is why you have to keep running git add all the time.)

---

¹ Technically, a commit doesn't so much contain the files as refer to the files. The files are stored using a series of indirections: commits point to tree objects, which give the name of the file, the mode, and a hash ID for the contents; and then the hash ID in the tree points to the Git blob object that saves the file's content. This allows two different trees (with maybe different modes or different sets of files) to re-use existing frozen file contents, and allows different commits (with maybe different authors or timestamps) to re-use existing frozen trees that re-use existing frozen commits. This is just one of several tricks that Git uses to save a lot of space, even though every commit stores a full and complete copy of every file: under the hood, there is a whole lot of re-use of old files.

² A commit normally lives forever, but if everyone who has some commit—as identified by some hash ID—agrees to stop using that commit forever and takes it out of the history-list, Git will eventually forget the commit for real. If anyone didn't agree, they can easily reintroduce the commit again, and in fact, that's the default. Commits are therefore hard to get rid of permanently once they've been spread to other Git repositories, because to get rid of them permanently, you have to ditch them from every Git repository that picked them up.