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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.