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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 5, 2023, 10:25 UTC
Message-ID: <xmqqjzs1mkma.fsf@gitster.g>
In-Reply-To: <871qeay6tz.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

> Just for better understanding: does it mean that *any* addition of
> one-letter option is prohibited from any existing Git command? Cause it
> definitely sounds this way.

No, we just prefer to think twice before giving short-and-sweet single letter option to a feature that is not proven useful, and during the discussion it has become rather clear that the proposed combination of options goes against helping normal Git users by forcing them to read an aggregated and redundant patch for a merge when they already see patches for individual commits on the side branch that was merged.

Show 8 quoted lines

>> 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, 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 am wondering if we can have a generalized "personal command option alias" mechanism implemented. Then you can give '-[a-z]'[*2*] to whatever combination you like without affecting others by only futzing with your $HOME/.gitconfig file.

[Footnote]

 *1* ...or if we are mimicking options of an existing external
     commmand, we need to match them, but in this case it does not
     apply.

 *2* If we were to do this for real, it may make sense to carve out
     option namespace so that end-user aliases cannot overlap with
     official set of options.  For example, if you can never get a
     string that matches "^-![a-z]$" recognised as an official
     command line option by our parsers, then '-!' followed by a
     single letter would be a good candidate for our "personal
     command option alias" to work with, and '-!d' might be
     something you want to use your personal option alias, without
     having to worry about a later version of Git using the option
     officially for something else.

     Another thing that need to be considered when designing such a
     "command option alias" feature is how to express the set of
     commands an alias applies to, as some underlying commands may
     share the same set of options.  For example, having to say

	optionAlias.bisect.1 = --first-parent
	optionAlias.blame.1 = --first-parent
	optionAlias.log.1 = --first-parent

     is a bit too cumbersome to allow me to say "git bisect -!1",
     "git blame -!1", and "git log -!1".  But I am not offhand sure
     if a much simpler

	optionAlias.1 = --first-parent

     is sufficient.  "git commit -!1" would expand into "git commit
     --first-parent" and would give you an error with the usage
     message, which may not be too bad.  I dunno.