From: Brian Lyles <brianmlyles@gmail.com>
Date: Sat, 27 Jan 2024 21:49:32 GMT
Subject: Re: [PATCH 3/4] rebase: Update `--empty=ask` to `--empty=drop`
Message-ID: <CAHPHrSefHb7KddWNS4NS2bAFG9DFfKZ=Ue499+EqDT3myS_tEA@mail.gmail.com>
In-Reply-To: <7032ae96-602f-499d-8430-a5dc3864d1bb@gmail.com>

Hi Phillip

On Tue, Jan 23, 2024 at 8:24 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
> On 19/01/2024 05:59, brianmlyles@gmail.com wrote:
> > From: Brian Lyles <brianmlyles@gmail.com>
> >
> > When `git-am` got its own `--empty` option in 7c096b8d61 (am: support
> > --empty=<option> to handle empty patches, 2021-12-09), `stop` was used
> > instead of `ask`. `stop` is a more accurate term for describing what
> > really happens,
>
> I can see your reasoning but I think of stopping as git's way of asking
> what to do so I'm not sure if "stop" is better than "ask". I don't know
> how we ended up with two different terms - the prior art is "ask" so
> maybe we should change "am --empty" instead. Lets see what others think.

The suggestion to use 'stop' instead of 'ask' for rebase was initially
Elijah's[1], which I agreed with. I am certainly open to others'
opinions here though, and am content with whatever is decided. I am
mostly aiming for consistency between git-rebase(1), git-am(1), and
ultimately git-cherry-pick(1).

[1]: https://lore.kernel.org/git/CABPp-BGJfvBhO_zEX8nLoa8WNsjmwvtZ2qOjmYm9iPoZg4SwPw@mail.gmail.com/

> It would be helpful to mention the tests in the commit message - we end
> up with a mixture of "--empty=ask" and "--empty=stop" I assume that is
> by design

You are correct -- the intent being to ensure that `--ask` continues
working for as long as it is supported. I'll add this to the message in
v2.

> > and consistency is good. This commit updates
> > `git-rebase` to also use `stop`, while keeping `ask` as a deprecated
> > synonym.
>
> If we're deprecating "ask" do we want to print a warning recommending
> "stop" instead?

That makes sense -- I will include a warning for this in v2.

Thanks,
Brian Lyles