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 (Oct 2023, #01; Mon, 2)
Date: Thu, 05 Oct 2023 23:59:17 +0300 [thread overview]
Message-ID: <87lecgeqfu.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqjzs1mkma.fsf@gitster.g> (Junio C. Hamano's message of "Thu, 05 Oct 2023 03:25:33 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Sergey Organov <sorganov@gmail.com> writes:
[...]
>>> 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".
>>
>> I'm afraid you need to pick a candidate that will be natural for '-d',
>> not just most useful output for your workflows, whatever it happens to
>> be.
>
> Literal match to word "diff" does not necessarily mean it is useful,
Sure, who argues? I don't.
> and short-and-sweet single-letter option name is primarily about
> letting users reach useful features with minimum typing [*1*], so you
> cannot avoid "most useful" being a large part of the equation.
I don't try to avoid "most useful" either, quite opposite. With whom do
you argue?
I just pointed that a short-cut would better be natural (or mnemonic)
/as well/, so you probably don't actually want:
-d:
give patches to all single-parent commits, and show tricky conflict
resolution part only for merge commits.
, or do you?
Overall, as an example, I'd understand if you had deflected the patch
with "let's rather use -d for '--decorate=short', or '--date=relative'",
or something like that, but you don't, leaving me uncertain about your
actual worries and intentions.
Anyway, I re-submitted the patches avoiding precious, too hard to
deserve single-letter option.
Thanks,
-- Sergey Organov
next prev parent reply other threads:[~2023-10-05 20:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-03 0:30 What's cooking in git.git (Oct 2023, #01; Mon, 2) Junio C Hamano
2023-10-03 7:01 ` Sergey Organov
2023-10-03 16:33 ` Junio C Hamano
2023-10-03 17:59 ` Sergey Organov
2023-10-04 8:20 ` Junio C Hamano
2023-10-04 11:18 ` Sergey Organov
2023-10-05 10:25 ` Junio C Hamano
2023-10-05 20:59 ` Sergey Organov [this message]
2023-10-05 21:47 ` Junio C Hamano
2023-10-06 18:02 ` Sergey Organov
2023-10-04 1:20 ` Eric W. Biederman
2023-10-04 16:28 ` Junio C Hamano
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=87lecgeqfu.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.