Lazy "new"

[spoerri]

It would be nice to banish empty commits, and to enable users not to have to care about them in the form of @- vs @. It would also be nice to be a little more opinionated and automatic for "squash workflow" vs "edit workflow". For example, users shouldn't have to care about whether to use new or edit for modifying vs viewing historical commits. #3129 #3660

Therefore, let's make new be lazy in the sense that a commit/change is only created when the working copy is actually modified.

I.e. for:

1. jj new [someExistingRev or not]
2. ...add, modify or delete a file in the working copy...
3. ...any jj command...

This proposal is to create the commit at 3 instead of 1.

Other niggles: would probably also want to go ahead and create the commit for jj describe modifications as well as working copy modifications. Might also want to rename new to something like "get", especially if there's openness to employ commit instead of new in one use case.

(And fun: to one way of looking at it, this would make the old "open" vs "closed" be a property of the working copy! The working copy would open either via edit or on a commit which it just created, and would close with new, commit, or edit of a different commit.)

[ilyagr]

let's make new be lazy in the sense that a commit/change is only created when the working copy is actually modified

I do sometimes want to jj edit a commit, especially if it's a WIP commit with no children. I'm not sure how to fit this in with a "lazy" new.

Also, this was just before my time, but jj did formerly have an open/closed concept, and then it was simplified away. See #321 (comment). I never learned precisely how that worked, but I imagine it was at least somewhat similar to what you are thinking.

[lgarron]

Another idea is to have some kind of symbol that means "the working-copy commit if non-empty, or the parent commit if empty".

I found this issue on GitHub search while trying to figure out how to make my own local flows more reliable. I'm currently very tempted to write myself a script to compute a way to refer to exactly this concept.

It is very common that I want to check out a commit, maybe perform some work/run some tests on it (or maybe leave it unchanged), and update + push the main bookmark from "the latest commit". Sometimes jj edit was the most appropriate approach to check out that commit, sometimes jj new was necessary.

This means that I have to sometimes move the bookmark to @ and sometimes to @- depending on whether the commit happens to be immutable — which can happen due to entirely unrelated reasons (e.g. whether the given commit happens to be part of another pushed branch).

I don't mind looking at the commit graph to orient myself, and I appreciate that gg lets me move the main bookmark very intuitively. But I would really like to be able to use a flow that does not require me to "look over my shoulder" every single time I want to push a branch.

[steveklabnik]

@lgarron you might be interested in various versions of an alias called tug that people use, here's one thread about it #5568

[lgarron]

@steveklabnik: ooh, thanks, very helpful! 🤩

[jennings]

This means that I have to sometimes move the bookmark to @ and sometimes to @- depending on whether the commit happens to be immutable

If you can really boil it down to that rule, you could make a revset alias to help, something like this:

'here' = 'coalesce(@ ~ empty() ~ immutable(), @-)'

Which evaluates to @ if it's mutable and non-empty, and @- otherwise.

[lgarron]

@jennings: Thanks, that was a really helpful starting point, and I'm definitely gonna try it.

A small detail is that I think going back to @- when @ is immutable (and non-empty) doesn't make sense to me¹. But after reading up on the revset language, I think this works?

'here' = 'coalesce(@ ~ empty(), @-)'

Footnotes

1. If I am editing a commit using --ignore-immutable then, well… I'm ignoring immutability already. ↩

[joyously]

This proposal is to create the commit at 3 instead of 1.

Despite you suggesting to rename new, I think the command should actually do its job when invoked. No one can predict the order or timing of commands to come. The next command might be from a different user, months after, or a tool, milliseconds after. Making a new commit is the expected result, or the command would not be used. It should be consistent, or it muddies up the mental model.
Is there some penalty for an empty commit?

[spoerri]

IMHO not aggressively creating commits is the correct mental model! I didn’t lead with that, lest I cause a tumult.

From a practical perspective, empty commits are not the end of the world. So far I’ve just seen trivial issues around @- and the correct semantics for jj next. To be clear, I don’t mean literally jj new but any command that creates a new commit in advance. jj commit is the most egregious. This is the sort of thing that increasingly many things come to rely on.

It’s more important to avoid a design that relies on empty commits because they are a smell in the model. We employ empty commits now as a replacement for “the parent commit is closed”, but the real problem with open/closed is that it doesn’t belong in the commits at all. It belongs in the working copy.

Multiple working copies ala workspaces might demonstrate: you can edit a commit in one workspace and view it in another. So having an empty commit as its child doesn’t accurately represent reality.

Or maybe we don’t even need to look at such an esoteric case; it’s just wrong to have users create new commits in order to view historical revisions. (Of course it’s also unfortunate to use jj edit for that.) IMHO jujutsu has great potential to “scale down” and be simple for newbies. So it’d be lovely to be able tell users “you can open up any revision with: jj get, and if you make any changes jujutsu will automatically and safely save them.” It’s hard to promote jujutsu as a simplified git if some of the most basic use cases require explaining revsets and squash vs edit workflows. Meet the new revision control same as the old revision control. Anyway, sorry to rant 😄

[joyously]

avoid a design that relies on empty commits because they are a smell in the model. We employ empty commits now as a replacement for “the parent commit is closed”, but the real problem with open/closed is that it doesn’t belong in the commits at all. It belongs in the working copy.

I don't think you have described the entire model. In my understanding, no commit is "closed", while the working copy as commit simplifies the interface and reduces possibility of lost work.

you can edit a commit in one workspace and view it in another.

If it's two workspaces, it's not the same commit? I can easily see how you can be editing a commit and view it in another window (no extra workspace needed). That's always the nature of multitasking. I just don't see what the contents have to do with it.

it’s just wrong to have users create new commits in order to view historical revisions.

I agree. I don't think they have to, however. There are other commands besides new.

So it’d be lovely to be able tell users “you can open up any revision with: jj get, and if you make any changes jujutsu will automatically and safely save them.”

I think this would be a big problem. I wrote up a similar sounding issue while I was testing out gg and it seemed very fragile if a novice could be browsing the repo, leaving a trail of changes from editor autosaves.

It’s hard to promote jujutsu as a simplified git if some of the most basic use cases require explaining revsets and squash vs edit workflows.

It's not a simplified git. The most basic use case doesn't need revsets or squash or edit either. Most basic is change files, then jj new. You don't even have to describe it. You can always simply march forward and ignore most of the commands.

[scott2000]

I personally prefer the current model because it feels very consistent since @ is always present and always refers to the working copy (meaning that it's empty if there are no changes made yet). I also wouldn't like the commit graph to change due to filesystem changes.

Maybe some of these issues could be resolved more easily by just adding a new revset called # which just means @-? So the "checked-out" commit would just be # always, and the working-copy commit would remain as @, and you could just configure jj log to hide @ if there's no changes so that you'd only see #. This has the benefit that all of the commands would still work the same as they do now (e.g. jj describe could still mean jj describe @).

So basically when you check out a commit, it would show that commit as # in the log (and the empty @ would be hidden). Then if you make changes, now @ would show up on top of #. But behind the scenes, the working copy would still always be accessible using @ regardless of if it's visible in the log.