Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, phillip.wood123@gmail.com,
	Johannes.Schindelin@gmx.de, bturner@atlassian.com,
	sami@boukortt.com, Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH v2 2/3] rebase: reinstate --no-keep-empty
Date: Fri, 10 Apr 2020 13:37:56 -0700
Message-ID: <xmqqtv1rhyaj.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <e15c599c874956f1a297424c68fe28e04c71807b.1586541094.git.gitgitgadget@gmail.com> (Elijah Newren via GitGitGadget's message of "Fri, 10 Apr 2020 17:51:33 +0000")

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> That commit viewed this, though as
> turning that flag into a no-op.

Sorry, but I do not understand this sentence.

> Provide users a way to drop commits which start empty using a flag that
> existed for years: --no-keep-empty.  Interpret --keep-empty as
> countermanding any previous --no-keep-empty, but otherwise leaving
> --keep-empty as the default.

But everything after that sentence down to here was very clear.

> This might lead to some slight weirdness since commands like
>   git rebase --empty=drop --keep-empty
>   git rebase --empty=keep --no-keep-empty
> look really weird despite making perfect sense (the first will drop
> commits which become empty, but keep commits that started empty; the
> second will keep commits which become empty, but drop commits which
> started empty).

That is true.  Do we leave it to others (or our later selves) to
think about the UI further?  That is fine by me, but in that case we
may want to add " We may want to rethink the option names later",
perhaps?

> +--no-keep-empty::
>  --keep-empty::
> +	Do not keep commits that start empty before the rebase
> +	(i.e. that do not change anything from its parent) in the
> +	result.  For commits which become empty after rebasing, see
> +	the --empty and --keep-cherry-pick flags.

keep-cherry-pick will appear later, not here, right?

Thanks.

  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09 23:26 [PATCH] rebase -i: mark commits that begin empty in todo editor Elijah Newren via GitGitGadget
2020-04-10  0:50 ` Junio C Hamano
2020-04-10  2:06   ` Bryan Turner
2020-04-10  4:57     ` Junio C Hamano
2020-04-10 17:51 ` [PATCH v2 0/3] " Elijah Newren via GitGitGadget
2020-04-10 17:51   ` [PATCH v2 1/3] " Elijah Newren via GitGitGadget
2020-04-10 17:51   ` [PATCH v2 2/3] rebase: reinstate --no-keep-empty Elijah Newren via GitGitGadget
2020-04-10 20:37     ` Junio C Hamano [this message]
2020-04-10 21:41       ` Elijah Newren
2020-04-10 17:51   ` [PATCH v2 3/3] rebase: fix an incompatible-options error message Elijah Newren via GitGitGadget
2020-04-10 20:42   ` [PATCH v2 0/3] rebase -i: mark commits that begin empty in todo editor Junio C Hamano
2020-04-10 21:04     ` Junio C Hamano
2020-04-10 21:14       ` Junio C Hamano
2020-04-10 22:11         ` Elijah Newren
2020-04-10 21:29     ` Junio C Hamano
2020-04-10 22:13       ` Elijah Newren
2020-04-10 22:30         ` Junio C Hamano
2020-04-11  0:07           ` Elijah Newren
2020-04-11 21:14             ` Junio C Hamano
2020-04-11  2:44   ` [PATCH v3 0/4] " Elijah Newren via GitGitGadget
2020-04-11  2:44     ` [PATCH v3 1/4] " Elijah Newren via GitGitGadget
2020-04-15 20:52       ` Junio C Hamano
2020-04-11  2:44     ` [PATCH v3 2/4] rebase: reinstate --no-keep-empty Elijah Newren via GitGitGadget
2020-04-11  2:44     ` [PATCH v3 3/4] rebase: fix an incompatible-options error message Elijah Newren via GitGitGadget
2020-04-11  2:44     ` [PATCH v3 4/4] rebase --merge: optionally skip upstreamed commits Jonathan Tan via GitGitGadget
2020-04-11 18:12       ` Jonathan Tan
2020-04-14  9:11     ` [PATCH v3 0/4] rebase -i: mark commits that begin empty in todo editor Phillip Wood

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=xmqqtv1rhyaj.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bturner@atlassian.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=newren@gmail.com \
    --cc=phillip.wood123@gmail.com \
    --cc=sami@boukortt.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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git