Creating new commit by prev/next commands shouldn't be implicit behavior

[kuchta]

I'm a bit confused that prev/next commands don't just edit (checkout/switch) to prev/next commit/revision but also create new empty commit. I suppose if somebody doesn't want to edit that particular commit they prev/next(/checkout/switched) to, they can always do a new commit using commit command or use some next/prev(/checkout/switch) parameter (e.g. -c for creating commit after that revision or -C to create a commit before that revision) to do so more conveniently. I know that next/prev has -e parameter to do so, but I think that creating new commits shouldn't be implicit behavior, but on the contrary more explicit since it doesn't change just WC (and possibly WC commit), but adds a new one even though their name doesn't convey that intention very well...

[amiryal]

The answer is somewhere in @thoughtpolice’s reply in the other discussion. Most of us use the squash workflow, as opposed to the edit workflow, which I think is the source of the confusion.

[kuchta]

I understand that most of the people are using squash workflow as probably most people used to the git index/staging area. I'm just advocating for general commands that can be used with whatever workflow anybody come up with, not some specific one, that most of you are used from the git...

[joyously]

Some of your confusion may be from thinking of commits(Git hashes) instead of changes(jj change IDs).
Also, don't think in terms of commands that don't exist (switch/checkout).

I think you can do whatever is needed in jj without ever using prev/next.

[kuchta]

I'm trying to not be bound by the current state of affairs, but to help build better ones. Maybe you prosper on confusion, but I like consitent things, at least on computers 😉

[bnjmnt4n]

I agree with this issue, this does seem like a slightly more inconsistent part of Jujutsu CLI. I think maybe something like jj next --new or jj next --create like you suggest seems like a good solution.

[kuchta]

I personally would call that option just -c/--commit so that it's clear that it would do a (empty) commit and possibly -C/--commit-before for people wanting that...

[martinvonz]

I agree with this issue, this does seem like a slightly more inconsistent part of Jujutsu CLI. I think maybe something like jj next --new or jj next --create like you suggest seems like a good solution.

Even though it it would be a bit annoying for me personally (because I basically never edit a non-head commit), I think I would be fine with that. This comes up very often, and I agree that the jj prev/next --edit behavior is more intuitive.

[kuchta]

I also don't plan to use it often, since changing the history is not a very good collaborative practice. I'm just of that opinion that it's better to build general enough and self-consitent tool and let people come up with whatever workflow they see fit...

[martinvonz]

(Btw, when is GitHub going to fix the annoying bug that clicking "Quote reply" creates a reply to the comment and a quote but the quote goes in the top-level answer box(!) ? My message was supposed to be a reply.)

[kuchta]

Exactly, I'm fighting with this all day here 👍😀

[kuchta]

I suppose it doesn't matter for non-important answers like this one, but it definitely shouldn't be default. One reason more for alternatives like https://radicle.xyz which I wanted to introduce to you anyway, if you don't know about it. But I suppose you do 😀 Would be great to have a native support for JJ, but I suppose as long as JJ uses git storage, it would be supported...

[kuchta]

When I think about it, is there a reason for next/prev being commands as opposed to just aliases of jj edit @+/jj edit @- or more preferably jj change-working-copy @+/jj change-working-copy @-. Then anybody could replicate current behavior with jj change-working-copy --new/-n @+/jj change-working-copy --new/-n @- or whatever term would be chosen for creating new commits (create/commit/..etc)