-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: rename --edit to --reword, and --cut to --split or --chop #40
Comments
As a native English speaker I think both of these suggestions make a lot of sense. I remember being confused by both of them. I was so eager to use the tool I got over it, but it's still not intuitive. Why does "split" conflict with "squash"? |
@alerque In an interactive revise, you can type |
Maybe |
I'd be open to supporting I'm more open to breaking changes to the interactive mode than the command line, which I wouldn't want to mess up anyone (including my) muscle memory with. |
|
I'd also appreciate |
Anecdotally, I did try to use ( |
I support this too |
In an interactive rebase, 'edit' means changing the contents of the commit, which is not available in revise. So
--edit
might be a bit confusing, as it actually corresponds to rewording a commit.Should this be renamed to
--reword
?As a non-native English speaker, when I encounter 'cut' in an application, I link it to cut/copy/paste (so: delete-and-place-on-clipboard). I think a term like 'split' covers the goal more clearly (supported by the fact that the man page explains the feature with 'split' and 'splitting').
This should not only impact command line option
--cut
, but also commandcut
in an interactive revise. Here,split
will conflict withsquash
. So maybechop
(and--chop
) is a feasible alternative?The text was updated successfully, but these errors were encountered: