All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Glen Choo <chooglen@google.com>, git@vger.kernel.org
Subject: Re: so/diff-merges-more (was Re: What's cooking in git.git (Feb 2023, #01; Thu, 2))
Date: Wed, 29 Mar 2023 10:43:55 +0300	[thread overview]
Message-ID: <87r0t80zpg.fsf@osv.gnss.ru> (raw)
In-Reply-To: <87y1nk6aa5.fsf@osv.gnss.ru> (Sergey Organov's message of "Sat, 25 Mar 2023 19:55:14 +0300")

Sergey Organov <sorganov@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Sergey Organov <sorganov@gmail.com> writes:
>>
>>>> I do not quite understand the last one (#4),
>>>
>>> Well, -m does not imply -p, whereas the rest of diff-merges options
>>> (-c/--cc/--remerge-diff) do imply -p. This is what half of this
>>> lengthy discussion was about.
>>>
>>>> own 4., it would be that introducing --diff-merges={kind} may have
>>>> been a mistake.  It would have been fine and better to just let
>>>> users choose from whatever set of options we support, i.e. (-c,
>>>> --cc, --remerge-diff, -m -p, -m --raw, ...).
>>
>>> It's fine with me that --cc is everything you need, but what I need is
>>> rather diff to the first parent, ...
>>
>> I think "show --first-parent" should give that already.
>
> Well, for "git show" even "show -m" does the right thing (once properly
> configured), as "-p" is implied by "git show".
>
> Taking "git show" into the picture brings yet another argument if favor
> of new "-m" behavior, as then "git show -m" and "git log -m -n1" will
> finally start to produce the same result, that I'd find desirable.
>
> That said,
>
>   --diff-merges=first-parent
>
> that could be shortened to
>
>   --diff-merges=1
>
> is the universal answer that works out-of-the-box for any command the
> same way, reliably, and then it's also
>
>   -m -p
>
> if configured accordingly, that has been made available by previously
> accepted patches.
>
> These series just did the last logical step: allowed it to be just
>
>   -m
>
> if configured accordingly.
>
>> One problem with "-m implies -p" is that it is unclear what should be
>> done to things like "-m --raw".
>
> Nothing specific is actually needed, as far as I'm aware, as implied -p
> doesn't interfere with --raw. Please give particular example of a
> problem if you foresee one.

In fact there is already a test for it that I added some time ago (as
well as for --stat), so a problem would have been caught. Please also
notice that it was an agreed goal for "-m" to finally imply "-p" at that
time:

commit 48229c193d2e6e728d3243bacea2f1e1490ced8a
Author: Sergey Organov <sorganov@gmail.com>
Date:   Fri May 21 00:46:55 2021 +0300

t4013: test "git log -m --raw"

This is to ensure we won't break different diff formats when we start
to imply "-p" by "-m".

Signed-off-by: Sergey Organov <sorganov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Thanks,
-- Sergey Organov

  reply	other threads:[~2023-03-29  7:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03  4:02 What's cooking in git.git (Feb 2023, #01; Thu, 2) Junio C Hamano
2023-02-04  9:33 ` Sergey Organov
2023-02-06 18:35   ` Junio C Hamano
2023-02-06 21:35     ` Sergey Organov
2023-03-01 18:40       ` Sergey Organov
2023-03-01 22:15         ` Junio C Hamano
2023-03-01 22:26           ` Sergey Organov
2023-03-01 23:54             ` Glen Choo
2023-03-02 14:38               ` Sergey Organov
2023-02-07  4:06   ` so/diff-merges-more (was Re: What's cooking in git.git (Feb 2023, #01; Thu, 2)) Glen Choo
2023-02-07 12:50     ` Sergey Organov
2023-03-02  0:37       ` Glen Choo
2023-03-02 16:15         ` Junio C Hamano
2023-03-02 16:57           ` Sergey Organov
2023-03-06 22:22             ` Glen Choo
2023-03-07 10:02               ` Sergey Organov
2023-03-07 17:54                 ` Junio C Hamano
2023-03-08 22:19                   ` Sergey Organov
2023-03-08 23:08                     ` Junio C Hamano
2023-03-09 13:54                       ` Sergey Organov
2023-03-09 17:43                         ` Glen Choo
2023-03-09 19:56                           ` Sergey Organov
2023-03-10 21:19                             ` Glen Choo
2023-03-10 21:47                             ` Junio C Hamano
2023-03-17 14:18                               ` Sergey Organov
2023-03-18  0:08                                 ` Junio C Hamano
2023-03-25 16:55                                   ` Sergey Organov
2023-03-29  7:43                                     ` Sergey Organov [this message]
2023-03-29  8:06                                     ` Sergey Organov
2023-02-08 17:22 ` ds/bundle-uri-5 (was: " Victoria Dye

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=87r0t80zpg.fsf@osv.gnss.ru \
    --to=sorganov@gmail.com \
    --cc=chooglen@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.