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

[Junio C Hamano <gitster@pobox.com>]

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.

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