git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).