Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >> 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. > >> 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
