Combine new and commit into one commit command

[kuchta]

WAS: default new to not changing working copy and instead use -e to do so as other commands

It's just three characters more (the reverse is 10 more), but it would be more consistent with other commands and the philosophy of not moving WC implicitly

[ilyagr]

What use-cases would this help? I implemented --no-edit, and I use it, but only <1% of the time. I understand your point about consistency, but at first impression, it just makes things so much less convenient. (It's possible that thinking about it would change the first impression, though)

I was going to say changing the default entirely would be too alien for git users, but I guess they'd have jj commit still (which I never use currently, but probably would with this change).

I'm not sure whether there are enough use-cases to provide a -N (or -E?) alias to --no-edit or to make this a config option.

[kuchta]

Well, I have no particular use-case in mind. I'm just learning jj so I suppose this could be taken as thinking of beginner mind when first encountering jj and trying to get it's operations model into the head. You are right that commit has a lot of common functionality with new so I suppose those two could be combined together as commit for more othogonal and simple set of commands, since there's also no oposite delete command but abandon one which goes quite nicely with commit and convey better what is does (and people are more used to it from other systems). Regarding naming commits, there could be then conventional --message/-m option for naming current commit and --describe/-d for naming the new commit or whatever else. Maybe it's just me, but I'm allways confused if there are multiple very similar ways to do the same thing, at least in the beginning...

[amiryal]

I would be in favour of such a change, if only to improve the ergonomics of creating new commits without switching to them.

@ilyagr: To continue your line of suggestion, I would suggest making it a configuration option and providing explicit overrides in the CLI:

-e, --edit
    Edit the newly created change

-E, --no-edit
    Do not edit the newly created change

However, it may make even more sense to add another command, say jj switch, to replace the current default behaviour of jj new (i.e. to edit the new commit immediately), and change the behaviour of jj new to always behave like --no-edit (i.e. no option to override with --edit; that’s what jj switch would be for).

[kuchta]

If there would be just a single commit command which I'm in favor for then making default behavior configurable and using explicit -e/-E (for automation etc.) is probably the best way how to go about it. Regarding switch I would rather use it instead of edit since that goes more hand in hand with those prev and next commands that also switch WC, but doesn't imply any "editing" which is IMHO a bit unfamiliar/confusing term in the context of VCS, so maybe it would be better to talk about switching (-s/S) than editing (-e/E) (or checkouting for that matter)

[joyously]

Please read the full explanation in discussion #3165, and take note of the commands (separate use of new and commit).

[joyously]

I think changing jj commands to match git commands is a bad idea, because they don't do quite the same thing.
Also, as a beginner, it sounds like you haven't yet looked into a command like jj new x m v u.

[kuchta]

I don't see how you came to the conclusion that I want to change jj commands to match git commands. It's actually the other way around. Wasn't that you, that defended inconsitent conventions from other systems (git) in the other discussion? BTW, I've looked on those commands, I just think that's more logical to have a command name commit that creates new commits (even "merge" commits)...

[joyously]

Well, you did change the name of this discussion to that: "Combine new and commit into one commit command".
The jj commit command is actually a combination of jj new and jj describe. I see no advantage to changing it. It would be more streamlined to remove the commit command so it could be an alias.

[joyously]

Wasn't that you, that defended inconsitent conventions from other systems (git) in the other discussion?

Yes it was me, but no I wasn't talking about command names as much as I was talking about the -m option being consistent.

[kuchta]

Being consistent in one thing with other systems doesn't make it self/internally consistent, which is more important trait, quite the contrary...

[joyously]

I think I'm missing something from your comments.
In my opinion, command names should be verbs. In that sense, new is not a good command name. Using commit is a problem, because most developers think of it as a noun, and the verb doesn't relate to the actual action. Not only that, but the noun is related to a specialty backend. If I wrote a quick Rust interface to Darcs for a backend, I would want to refer to patches and not commits.