Re: diff-index --cc no longer permitted, gitk is now broken (slightly)

Junio C Hamano [off-list ref] writes:

Johannes Sixt [off-list ref] writes:

quoted

Since 19b2517f95a0 (diff-merges: move specific diff-index "-m" handling
to diff-index, 2021-05-21) git diff-index no longer accepts --cc. This
breaks gitk: it invokes

   git diff-index --cached -p -C --cc --no-commit-id -U3 HEAD

to show the staged changes (when the line "Local changes checked in to
index but not committed" is selected).

The man page of git diff-index does not mention --cc as an option. I
haven't fully grokked the meaning of --cc, so I cannot tell whether this
absence has any significance (is deliberate or an omission).

Is gitk wrong to add --cc unconditionally? Should it do so only when
there are conflicts? Or not at all?

I think --cc is designed to naturally fall back to -p when there is
only one parent.  Use of both -p and --cc has also long been an
acceptable combination, and even if we say the later --cc overrides
-p, there is no reason not to show single parent patch here with
--cc.

Another tangent.

I think the use of --cc with diff-index can make sense in another
way.

    $ echo "# both" >>COPYING
    $ git add COPYING
    $ echo "# work" >>COPYING

Now we have one extra line at the end in both the index and the
working tree file, with yet another at the end of the latter.

    $ git diff-index --cc HEAD

is a way to show combined diff to go to the working tree version
starting from HEAD and starting from the index (I needed to use an
old version because the 'maint' and upwards are broken as reported).

    $ rungit v1.5.3 diff-index --cc HEAD
    diff --cc COPYING
    index 8b9c100,536e555..0000000
    --- a/COPYING
    +++ b/COPYING
    @@@ -358,4 -358,3 +358,5 @@@ proprietary programs.  If your program 
      consider it more useful to permit linking proprietary applications with the
      library.  If this is what you want to do, use the GNU Lesser General
      Public License instead of this License.
     +# both
    ++# work

Now the way "gitk" used is with "--cached", so there is no multi-way
comparisons to be combined, and it is natural to fall back to "-p",
so it is a different issue, but since we invented "--cc" to
originally emulate, and to later improve, the output from gitk,
I am reasonably sure that its use of "--cc" should be supported.