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

Junio C Hamano [off-list ref] writes:

Sergey Organov [off-list ref] writes:

quoted

I'm afraid this issue is left up in the air after application of the
fix-up patch, as usage of --cc in the diff-index is still undocumented.

Yeah, I do think documentation update is needed, but being buried by
other topics I haven't had a chance to revisit the way how --cc is
described in the wider context in order to make an intellgent
suggestion on how to present it in the context of "diff-index".

I tend to believe yet another description of --cc is needed for
diff-index, separate from the current one. Just saying.

quoted

I.e., the fix-up just restores the historical status quo that has a
problem by itself.

I do agree "show -p" on merge is an oddball that trips new people,
because it does not imply the "do present the changes for merges"
bit unlike "show -c/--cc" do, and from that point of view, the
generalization --diff-merges tried to bring us was a good thing.

I'm not sure I follow. What "show -p" has to do with "diff-index --cc"?

My only point here is that usage of *--cc* in *diff-index* is entirely
undocumneted, and that needs to be somehow resolved.

But "-c/--cc" are explicit enough in what they want to do.  It does
want to present the changes to compare a single end state with
possibly more than one starting state (e.g. a merge) and not
requiring an explicit "-m" is quite natural.

Doesn't seem to be relevant for "diff-index --cc" lacking documentation,
but -m and -c and --cc are rather *mutually exclusive*. I.e., they all
set different formats for output of diffs for merges, so "--cc -m" ==
"-m", and "-m --cc" == "--cc", i.e., the latest overrides the format to
be used. Therefore "requiring explicit -m for -cc" simply doesn't make
sense.

Even more, when it compares the end state with only one starting state
(e.g. showing a single parent commit), there is only one pairwise
result to "combine", so it is also natural that it ends up showing the
same output as "-p". So I do not quite see the behaviour of
"diff*/show --cc" as a problem, though.

I don't see it as a problem as well, so whom you are arguing with?

The only problem in this particular case I see is that "diff-index --cc"
is undocumented (and untested), and this has nothing to do with
log/diff/show, unless I miss your point.

IOW, the use pattern in gitk is more than just "historical status
quo", but is quite sensible, I would have to say.

"diff-index --cc" in gitk is a bug, as according to Git documentation
"diff-index" does not accept "--cc", period.

gitk trying to make sense of what is neither documented, nor tested, nor
guaranteed is the problem, but I was talking even not about that
problem, but rather about the cause of this: some undocumented
processing of "git diff-index --cc".

Thanks,
-- Sergey Organov