Junio C Hamano <gitster@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Johannes Sixt <j6t@xxxxxxxx> writes: >> >>> 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. If the patch breaks essential (even if undocumented and untested) behavior, as Jeff pointed, it should obviously be fixed. I'll look at it more closely to suggest a fix. Thanks, -- Sergey Organov
