On Fri, Oct 08, 2021 at 10:45:59PM +0200, Christian Weisgerber wrote:
> How about going one step further and mandating "-c ... -c ..." for
> diffing two objects, and dropping this magic use of "object1 object2"
> we have now?

I like how this idea would remove some ambiguity which the current
implementation needs to cope with.
I have started to write a patch for this and have arrived at a question:

How would you handle other object types, such as when comparing two blobs
or two trees with each other?

Using -c options seem inappropriate for this purpose since we normally
use -c to refer to a "commit".
(I would let tag objects be covered by -c because tags usually point
at commit or tree objects, even though this is not enforced by Git.)

Should we have even more options?

  diff -b blob1 -b blob2 ?
  diff -t tree1 -t tree2 ?

Where -b, -t, and -c are all mutually exclusive?

Or would we want to use a single option for all object types?
What would be a good mnemonic for this?

diff -o object1 -o object2 ?
diff -i id1 -i id2 ?

I am not sure what a single -o/-i option should do for blobs.
Error out? Or compare the blob to a file in the work tree if
a path to a file was provided?

Otherwise, path arguments only make sense when diffing trees,
or, by extension, commits. But not when diffing two blobs:

  diff -i blob1 -i blob2 -> ok
  diff -i blob1 -i blob2 path -> error?
  diff -i tree1 -i tree2 path -> ok
  diff -i commit1 -i commit2 path -> ok

All considered this seems more complicated to use than the current
'object1 object2' syntax, which is quite intuitive since it mirrors
the standard diff use case: diff file1 file2

Regarding a single -c option: We do not yet have a diff driver for
comparing the work tree against a repository tree. Diff drivers we
have implemented so far can compare the work tree to the file index,
and compare two in-repository trees. Therefore, making a single -c
option work as a shortcut for comparing a commit to its parent commit
would be less effort than writing a new diff driver which compares a
tree object to a work tree. Yet, of course, such code could be written.
But is it worth doing if we are not yet sure that it is really going
to be needed?