FR: jj commit <path> supports committing a subset of changed files

[kevincliao]

Sometimes I have locally modified files that are not intended to be submitted. To commit a subset of the files, it's recommended to run jj split <path>. However split requires opening up the editor 2 times and writing multiple commit descriptions (even if just left empty). For people that don't have the habit of deciding the working copy's commit description beforehand, part of the workflow is redundant.

It would be great if jj commit -m "msg" <path> could be supported. It works the same way in git and hg, so no re-learning. Plus it's a single command that doesn't require a multi-step split.

[yuja]

However split requires opening up the editor 2 times

iirc, there was a discussion about making the 2nd editor optional (opens only if the wc commit already had a description.) I think that's also a good idea.

I'm not sure if jj commit should support splitting behavior, but at least, it can provide a hint if <path> argument is specified.

[PhilipMetzger]

I think at this point a jj commit --interactive should be a better solution, as it allows partial committing files while not losing the benefit of the working copy commit. See #1905 (comment) and our previous discussion in Discord, starts here.

[kevincliao]

Thanks for bringing in the context. Having jj split 2nd editor optional seems like a close enough solution. I guess I'm still not used to the thought that working copy is a commit, so as intuitive as jj commit seems, split is the command responsible.

Have there been discussion for split to not open editors (like -m in commit)? I personally tend to prefer non-editor workflows since it's a one-step process and bash/zsh_history memorized. And that's what jj commit could do.

I'm not familiar with jj commit --interactive. Would the experience be similar to jj commit that allows opening up an editor to select paths? One case that maybe should be covered is regular expressions like jj commit -m "msg" lib/*.

[martinvonz]

Have there been discussion for split to not open editors (like -m in commit)? I personally tend to prefer non-editor workflows since it's a one-step process and bash/zsh_history memorized. And that's what jj commit could do.

I don't think there has been. I think I made jj split ask for descriptions just because that's what hg split does. I don't think I considered doing it differently. Still, I think it would be confusing if we assigned the old description to both commits. That seems like it would almost never be what user would want. Sure, they could edit either of them afterwards, but they would probably do that right away in most cases anyway, so we might as well ask them then.

I'm not familiar with jj commit --interactive. Would the experience be similar to jj commit that allows opening up an editor to select paths? One case that maybe should be covered is regular expressions like jj commit -m "msg" lib/*.

You can already do jj split lib, which adds the changes to lib/ in the first commit and the remaining changes in the second commit. We don't support globs or regular expressions yet, however.

[PhilipMetzger]

Thanks for bringing in the context. Having jj split 2nd editor optional seems like a close enough solution. I guess I'm still not used to the thought that working copy is a commit, so as intuitive as jj commit seems, split is the command responsible.

No problem at all, I just think everyone should get a full context if its available.

Have there been discussion for split to not open editors (like -m in commit)? I personally tend to prefer non-editor workflows since it's a one-step process and bash/zsh_history memorized. And that's what jj commit could do.

Not that I'm aware of.

I'm not familiar with jj commit --interactive. Would the experience be similar to jj commit that allows opening up an editor to select paths? One case that maybe should be covered is regular expressions like jj commit -m "msg" lib/*.

AFAIU, it behaves like git add -p, so it should be orthogonal to support paths.

[kevincliao]

Sounds good. Closing this issue.

[arxanas]

Are we certain that we want to close this? I would personally use a jj commit commands with paths, even in the presence of an improved jj split.

[kevincliao]

I would personally use a jj commit commands with paths, even in the presence of an improved jj split.

It seems nice to be consistent with other vcs like git/hg here for ease of use.

[arxanas]

This was implemented in #2132.