Re: [PATCH v1 0/5] diff-merges: more features to fix '-m'

From: Sergey Organov <sorganov@gmail.com>
Date: Dec 19, 2022, 14:29 UTC
Message-ID: <87bknzfow4.fsf@osv.gnss.ru>
In-Reply-To: <xmqqbko1xv86.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> > Sergey Organov <sorganov@gmail.com> writes:
> > * implying '-p' by '-m' by default broke some legacy uses of
> >   "git log --firt-parent -m".
> 
> ... like so.  Without learning from the experience, we may repeat
> doing the same thing over and over and expecting different outcome,
> but it would not give us a very good end-user experience if it
> breaks them every time we try doing that.

The experience tells that this form was likely the only useful form of using -m, and then it has been obsoleted for more than two years already, since --first-parent started to imply -m:

https://lore.kernel.org/git/20200728163617.GA2649887@coredump.intra.peff.net/

[...]

> IIRC, the previous round (why is this round marked as v1, by the
> way?)

Well, everybody knows indexing always starts at 0, right? ;-)

Now, "git format-patch" has the --reroll-count=N, and as that was the first re-roll, I've used "1" for that. Is this my mistake?

> was reviewed by some folks, so lets wait to hear from them
> how this round does better.

Yes, correct.

Show 7 quoted lines

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

Dunno, but similar issue with --cc apparently was worth resolving when you've changed its behavior back in 2015:

https://lore.kernel.org/git/1440110591-12941-3-git-send-email-gitster@pobox.com/

The '-m' not behaving as people expect is an issue that I'm trying to solve.

Thanks, -- Sergey Organov