From: Sergey Organov Date: Mon, 19 Dec 2022 14:29:15 GMT Subject: Re: [PATCH v1 0/5] diff-merges: more features to fix '-m' Message-ID: <87bknzfow4.fsf@osv.gnss.ru> In-Reply-To: Junio C Hamano writes: > > Sergey Organov 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. > > 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