Duy Nguyen [off-list ref] writes:
On Thu, Dec 8, 2016 at 3:04 AM, Junio C Hamano [off-list ref] wrote:
quoted
Stephan Beyer [off-list ref] writes:
quoted
[1] By the way: git cherry-pick --quit, git rebase --forget ...
different wording for the same thing makes things unintuitive.
It is not too late to STOP "--forget" from getting added to "rebase"
and give it a better name.
Having the same operation with different names only increases git
reputation of bad/inconsistent UI. Either forget is renamed to quit,
or vice versa. I prefer forget, but the decision is yours and the
community's. So I'm sending two patches to rename in either direction.
You can pick one.
I actually was advocating to remove both by making --abort saner.
With an updated --abort that behaves saner, is "rebase --forget"
still necessary?
Hi Junio,
On 12/09/2016 07:07 PM, Junio C Hamano wrote:
Duy Nguyen [off-list ref] writes:
quoted
Having the same operation with different names only increases git
reputation of bad/inconsistent UI. Either forget is renamed to quit,
or vice versa. I prefer forget, but the decision is yours and the
community's. So I'm sending two patches to rename in either direction.
You can pick one.
I actually was advocating to remove both by making --abort saner.
With an updated --abort that behaves saner, is "rebase --forget"
still necessary?
A quick change in t3407 of the "rebase --forget" test to use "rebase
--abort" failed. That's because it checks the use-case of
forgetting/aborting without changing the HEAD. So --abort makes a
rollback, --forget just keeps the current head. I am not sure if that
tested use-case is a real use-case though.
A quick change in the pristine_detach function in t3510 and t3511 from
"cherry-pick --quit" to "cherry-pick --abort" works when one ignores the
return value of "cherry-pick --abort". The "--quit" is used here to
ensure a clean cherry-pick state, and --quit always succeeds, even if no
cherry-pick is in progress. That may be a real use-case somehow that
could also be used for "rebase --forget"
t3510 also shows another use-case for --quit: the title says it all:
"cherry-pick --quit" to "cherry-pick --abort"
With this additional information, I'd vote to keep --quit/--forget and
just make it consistent.
~Stephan
On 12/09/2016 08:24 PM, Stephan Beyer wrote:
t3510 also shows another use-case for --quit: the title says it all:
"cherry-pick --quit" to "cherry-pick --abort"
I should've read what I actually pasted.
I wanted to paste: '--quit keeps HEAD and conflicted index intact'
Sorry for making no sense ;)
With this additional information, I'd vote to keep --quit/--forget and
just make it consistent.
Now!
~Stephan
On Sat, Dec 10, 2016 at 2:24 AM, Stephan Beyer [off-list ref] wrote:
Hi Junio,
On 12/09/2016 07:07 PM, Junio C Hamano wrote:
quoted
Duy Nguyen [off-list ref] writes:
quoted
Having the same operation with different names only increases git
reputation of bad/inconsistent UI. Either forget is renamed to quit,
or vice versa. I prefer forget, but the decision is yours and the
community's. So I'm sending two patches to rename in either direction.
You can pick one.
I actually was advocating to remove both by making --abort saner.
With an updated --abort that behaves saner, is "rebase --forget"
still necessary?
A quick change in t3407 of the "rebase --forget" test to use "rebase
--abort" failed. That's because it checks the use-case of
forgetting/aborting without changing the HEAD. So --abort makes a
rollback, --forget just keeps the current head. I am not sure if that
tested use-case is a real use-case though.
It is. I wanted something like this for years but "rm -rf
/path/to/.git/rebase*" was not as bad when there were no linked
worktrees.
rebase and cherry-pick/revert are not exactly in the same situation.
When cherry-pick/revert in "continue/abort" mode, there's usually some
conflicted files and it's easy to notice.
But an interactive rebase could stop at some commit with clean
worktree (the 'edit' command). Then I could even add some more commits
on top. I don't see how 'rebase --abort' can know my intention in this
case, whether I tried (with some new commits) and failed, and want to
revert/abort the whole thing, moving HEAD back to the original; or
whether I forgot I was in the middle of rebase and started to do
something else, and --abort needs to keep HEAD where it is.
--
Duy