From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Feb 2023, #01; Thu, 2)
Date: Tue, 07 Feb 2023 00:35:59 +0300 [thread overview]
Message-ID: <87357ischs.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqedr28wwb.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 06 Feb 2023 10:35:32 -0800")
Junio C Hamano <gitster@pobox.com> writes:
> Sergey Organov <sorganov@gmail.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>
>>> * so/diff-merges-more (2022-12-18) 5 commits
>>> - diff-merges: improve --diff-merges documentation
>>> - diff-merges: issue warning on lone '-m' option
>>> - diff-merges: support list of values for --diff-merges
>>> - diff-merges: implement log.diffMerges-m-imply-p config
>>> - diff-merges: implement [no-]hide option and log.diffMergesHide config
>>>
>>> Assorted updates to "--diff-merges=X" option.
>>>
>>> May want to discard. Breaking compatibility does not seem worth it.
>>> source: <20221217132955.108542-1-sorganov@gmail.com>
>>
>> Hi Junio,
>>
>> This does not break any compatibility, as far as me and I believe
>> reviewers of these series are aware.
>
> The last paragraphs in the review two months ago still describe what
> this series does fairly accurately, I think.
>
> These patches do look like a good approach to solve the first point
> among the "two problems" in the previous round. Thanks for working
> on it.
>
> IIRC, the previous round (why is this round marked as v1, by the
> way?) was reviewed by some folks, so lets wait to hear from them
> how this round does better.
>
> Unfortunately, I do not think of any "solution" that would avoid
> breaking folks, if its end goal is to flip the default, either by
> hardcoding or with a configuration variable. IOW, the other one
> among the "two problems" in the previous round sounds unsolvable.
> We should question if it was really an "issue" worth "resolving",
> though.
Well, we may end up flipping or not flipping the default (even though
I'd prefer we indeed do), the series are still valid either way, as they
allow *me* (or anybody else who prefers more useful '-m' behavior) to
flip the switch for myself, locally.
Also, the only patch that got some resistance from reviewers has been
removed from the series, so I don't see anything left that'd prevent
this from being merged.
From my POV the only remotely questionable patch is:
- diff-merges: issue warning on lone '-m' option
and I hereby agree to remove it if it feels wrong to you.
Let me state it cleanly: once these are accepted, I'll turn
log.diffMerges-m-imply-p on for myself, and will suggest it to others
who already asked about '-m' inconsistency, or will ask in the future.
Thanks,
-- Sergey Organov
next prev parent reply other threads:[~2023-02-06 21:36 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 [this message]
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
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=87357ischs.fsf@osv.gnss.ru \
--to=sorganov@gmail.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.