John Keeping <> writes:

>>  - When comparing two revisions, e.g. "--dir-diff HEAD^^ HEAD^",
>>    that checks out (via $rsha1 to "checkout -f" codepath) a blob
>>    that does not match what is in the working tree of HEAD to the
>>    temporary directory, we still allow modifications to the copy in
>>    the temporary directory, but what can the user do with these
>>    changes that are _not_ based on HEAD, short of checking out HEAD^
>>    and apply the difference first?
>> I still cannot shake this nagging feeling that giving a writable
>> temporary directory might have been a mistake in the first place.
>> Perhaps it may be a better design to make the ones that the user
>> shouldn't touch (or will lead to the above confusion) read-only,
>> while the ones that match the working tree read-write?
> My ideal scenario would be that we only allow users to edit files when
> they are comparing against the working tree, but that would require
> git-difftool to fully understand all git-diff options since it just
> passes through any it doesn't recognise.  I don't think there's an easy
> way to do that, which leaves us with this confusing situation.

Not necessarily.

Let's assume that changing files in "diff" tool is a sensible thing
to do, as long as we make sure such a change is not lost (which I
may not 100% agree with, but let's put it aside for now).

When you are viewing a file F in "--dir-diff HEAD^^ HEAD^", if there
is no change for F in between HEAD^ and HEAD and you notice a typo
that may or may not be related to the differences between HEAD^^ and
HEAD^, it would be tempting to fix that right there.  And as long as
F in the working tree matches that of HEAD^ and the modification you
make in the temporary directory gets copied back to the working tree,
your typofix will end up to be in the working tree.

Which I _think_ is what people, who want to change files in "diff"
tool, want to do.

Of course, your working tree may have been in the middle of doing
something entirely different and you may have to "add [-p]" to
separate such a typofix with other changes you were working on, but
that is a separate issue.

And for that to work, the only think you need is "does the blob we
show on the RHS temporary tree match what is in the working tree?"
check.  You do not need to know or care if you are comparing two old
revisions, etc.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to