git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Teng Long <dyroneteng@gmail.com>
Cc: --cc=avarab@gmail.com, git@vger.kernel.org, me@ttaylorr.com,
	tenglong.tl@alibaba-inc.com
Subject: Re: [RFC PATCH 0/1] push: introduce '--heads' option
Date: Fri, 28 Apr 2023 11:48:43 -0700	[thread overview]
Message-ID: <xmqq7ctvetbo.fsf@gitster.g> (raw)
In-Reply-To: <20230428095955.66292-1-tenglong.tl@alibaba-inc.com> (Teng Long's message of "Fri, 28 Apr 2023 17:59:55 +0800")

Teng Long <dyroneteng@gmail.com> writes:

> ZheNing Hu mentioned me that could use "OPT_ALIAS" instead, it seems
> like could be better than OPT_BIT in this scenario. If so, are problems
> that may arise from interactions shielded? If not, I'm willing to add
> extra test about it (some relevant advice if possible).

The intent of ALIAS is to just add an extra option visible at the UI
level that behaves exactly the same as the other one at the code
level, so the codepath that is prepared to deal with one can handle
the other one without any extra effort.  In fact, after the option
parsing is finished, the rest of the code should not even be able to
tell which one, the original or the alias, was used on the command
line.

And in this case, you'd want a new "push all branches" option that
behaves exactly like existing "--all", and possibly you may over
time want to deprecate the latter.  All the code to ensure how
"--all" should interact with other options should be working fine
(or if there is a bug, that needs to be corrected whether we would
add this alias or not).

Sounds like a very good plan to me.

Thanks.


  reply	other threads:[~2023-04-28 18:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 13:35 [RFC PATCH 0/1] push: introduce '--heads' option Teng Long
2022-12-05 13:35 ` [RFC PATCH 1/1] " Teng Long
2022-12-05 14:23   ` ZheNing Hu
2022-12-06 12:18     ` Teng Long
2023-04-28 12:21   ` Felipe Contreras
2023-04-30  1:05     ` Teng Long
2023-05-06 11:27   ` [PATCH 0/1] push: introduce '--branches' option Teng Long
2023-05-06 11:27     ` [PATCH 1/1] " Teng Long
2023-05-06 11:36     ` [PATCH 0/1] " Teng Long
2022-12-05 23:35 ` [RFC PATCH 0/1] push: introduce '--heads' option Junio C Hamano
2022-12-15 12:27   ` Teng Long
2023-04-28  9:59   ` Teng Long
2023-04-28 18:48     ` Junio C Hamano [this message]
2023-04-30  1:09       ` Teng Long
2023-05-06 11:34 ` [PATCH 0/1] push: introduce '--branches' option Teng Long
2023-05-06 11:34   ` [PATCH 1/1] " Teng Long
2023-05-06 21:39     ` Junio C Hamano
2023-05-07  6:43       ` Teng Long

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq7ctvetbo.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=--cc=avarab@gmail.com \
    --cc=dyroneteng@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=tenglong.tl@alibaba-inc.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).