Re: What's cooking in git.git (Oct 2023, #01; Mon, 2)

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 4, 2023, 08:20 UTC
Message-ID: <xmqqo7hessro.fsf@gitster.g>
In-Reply-To: <874jj7lh7x.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

Show 15 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Sergey Organov <sorganov@gmail.com> writes:
>>
>>> I believe I've addressed this in details in my reply here:
>>> <87o7hok8dx.fsf@osv.gnss.ru>, and got no further objections from you
>>> since then, so I figure I'd ask to finally let the patch in.
>>
>> You need to know that no response does not mean no objection.  You
>> repeated why the less useful combination is what you want, but that
>> does not mean the combination deserves to squat on short-and-sweet
>> 'd' and prevent others from coming up with a better use for it.
>
> Yep, but I've asked what's better use for -d than "get me diff"? Do you
> really have an idea?

The primary point is to leave it open for future developers.

If I have to pick a candidate for "get me diff" that is the most useful among those currently are available, it is "give patches to all single-parent commit, and show tricky conflict resolution part only for merge commits". Before "--remerge-diff" was invented, my answer would have been "give patches to all single-parent commit, and show combined diff in the compact form for merge commits", aka "git log --cc". Even though we did not know if a better output presentation for merge commits would be coming, we did not let it squat on any short-and-sweet single letter synonym.