From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j6t@kdbg.org>, Jeff King <peff@peff.net>,
Paul Mackerras <paulus@ozlabs.org>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: diff-index --cc no longer permitted, gitk is now broken (slightly)
Date: Fri, 17 Sep 2021 01:41:44 +0300 [thread overview]
Message-ID: <874kaki1nb.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqy27wrzmj.fsf@gitster.g> (Junio C. Hamano's message of "Thu, 16 Sep 2021 14:15:16 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Sergey Organov <sorganov@gmail.com> 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
next prev parent reply other threads:[~2021-09-16 22:41 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 8:03 diff-index --cc no longer permitted, gitk is now broken (slightly) Johannes Sixt
2021-08-30 13:05 ` Sergey Organov
2021-08-30 18:13 ` Jeff King
2021-08-30 20:01 ` Sergey Organov
2021-08-30 20:26 ` Johannes Sixt
2021-08-30 20:45 ` Sergey Organov
2021-08-30 17:12 ` Junio C Hamano
2021-08-30 17:40 ` Sergey Organov
2021-08-30 18:09 ` Junio C Hamano
2021-08-30 20:03 ` Sergey Organov
2021-09-01 16:52 ` Sergey Organov
2021-09-07 18:19 ` Junio C Hamano
2021-09-07 19:53 ` Sergey Organov
2021-09-08 13:43 ` Sergey Organov
2021-09-08 17:23 ` Johannes Sixt
2021-09-08 19:04 ` Sergey Organov
2021-09-09 17:07 ` Junio C Hamano
2021-09-09 20:07 ` Sergey Organov
2021-09-16 9:50 ` Sergey Organov
2021-09-16 21:15 ` Junio C Hamano
2021-09-16 22:41 ` Sergey Organov [this message]
2021-09-16 22:50 ` Junio C Hamano
2021-09-17 7:08 ` Sergey Organov
2021-09-17 16:32 ` Junio C Hamano
2021-09-17 18:41 ` Sergey Organov
2021-09-17 16:58 ` Philip Oakley
2021-09-17 17:34 ` Sergey Organov
2021-09-18 17:56 ` Sergey Organov
2021-09-07 20:32 ` Johannes Sixt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874kaki1nb.fsf@osv.gnss.ru \
--to=sorganov@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=paulus@ozlabs.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).