All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 06 Oct 2023 21:02:40 +0300	[thread overview]
Message-ID: <87il7jr5mn.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqh6n4eo7n.fsf@gitster.g> (Junio C. Hamano's message of "Thu, 05 Oct 2023 14:47:24 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> 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.
>
> Oh, I would be very much more sympathetic if somebody wanted to make
> a short-and-sweet single-letter option to stand for "--first-parent
> -p", if they come with the "first-parent chain is special---it is
> the trunk history of the development" world view.  And the resulting
> behaviour would be "give me the diffs" in their world view, so I
> would understand if they wanted to use "-d" for such an operation.
>
> However, to folks who do not subscribe to "the first parent chain is
> the trunk history" world view, "give me the diffs" is not an
> explanation of the resulting behaviour, because in "-d" there is no
> trace of hint that it is also about first-parent traversal.  
>
> So "-d" may not be a perfect fit for it, either.  But at least it is
> based on a more consistent world view, I would think, than
> "--diff-merges=1 -p", whose behaviour becomes unexplainable when it
> hits "reverse" merges in a world where the first parent chain is not
> necessarily the trunk.
>
> Anyway, I've tentatively queued the "--dd" round.  Naming is hard,
> I cannot tell what "dd" stards for, and I suspect no user can X-<.

Thanks, it stands for diff-diff (for both merges and regulars), and got
inspired by --cc as well. Also selected as being fairly easy to type.

Should I add this to the commit message?

-- Sergey Organov

  reply	other threads:[~2023-10-06 18:02 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
2023-10-05 21:47               ` Junio C Hamano
2023-10-06 18:02                 ` Sergey Organov [this message]
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=87il7jr5mn.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.