Hi Phillip On Tue, Jan 23, 2024 at 8:24 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > On 19/01/2024 05:59, brianmlyles@xxxxxxxxx wrote: > > From: Brian Lyles <brianmlyles@xxxxxxxxx> > > > > 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@xxxxxxxxxxxxxx/ > 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
