Creating implicit commits when abandoning current WCC

[kuchta]

I think it's a bad practice to implicitly create news commits when the user doesn't explicitly ask for it.

Possible solution: move WCC to it's parent and in case of multiple parents, randomly choose one and print warning

Relates to prev, next and possibly others...

[bnjmnt4n]

Note that this is the default behavior for all commands: a working-copy commit emptied by a command will always create a new working-copy commit. Perhaps we should create a new flag which avoids creating a new working-copy commit and updates the working copy to be a parent instead?

[kuchta]

@bnjmnt4n Yes, it looks like a default behavior, which is quite counter-intuitive and although not destructive, it's something I think should be avoided as possible. I'm personally in favor of the opposite solution, don't make implicitly new commit, but either use some parameter like --commit/-c for explicitly creating one or preferebly by user defined functions that can utilize multiple commands in sequence, which would make basic command set simpler...

[kuchta]

Well, I'm now quite interested what actually happens when you abandon a commit? Does jj delete it, or set the parent to none? How would jj in the future implement GC, if it's not based on branches? In branch model it's simple, whatever you can't follow backwards to root is collected, but in a branchless model... Would you take opposite approach of following root commit forward and collecting everying not found?

[ilyagr]

Well, I'm now quite interested what actually happens when you abandon a commit?

Whether a commit is visible is an extra piece of metadata stored in jj's store (outside the part that's managed by git, same place where the change id of a commit is remembered). There are also some rules that should be enforced by jj: the working copy is always visible, ancestors of visible commits are also visible.

[kuchta]

Thank you @ilyagr for clarification. And the default is that everything is visible until abandoned? Can actually some ancestor of a visible commit be invisible if abandon rebases it's target descendants onto it's parent?

[ilyagr]

The primary ways commits become hidden is when you edit them or rebase them.

As the tutorial explains, any change to the working tree changes the commit id of the current change. This means that the old commit became hidden and a new visible commit was created with the same change id.

Similarly, when you rebase a commit, the old version becomes hidden, and a new visible commit with the same change id is created.

You can see all the hidden "previous versions" of commits by running jj obslog.

jj abandon hides a commit without creating a replacement visible commit. Then, a rebase automatically happens, but you can think of this as a separate operation. (Strictly speaking, for the rules I described to always hold, the rebase would logically have to happen first, so that the commit doesn't have any visible descendants when it becomes hidden)

[kuchta]

Oh of course, I didn't realize that, thank you, @ilyagr 🙏🏻

[kuchta]

No, but I also wouldn't expect it to open the previously edited file, and allow me to continue editing it (hoping that I would read the warning).

it's only logical you HAVE TO change it to something and so the user will expect that to happen, so it's intuitive

As mentioned above, an alternative would be to error if the commit to abandon is the working copy commit.

Okay, I agree. That is probably even better default, especially when you can do jj restore to achieve basicaly the same thing

but creating new commit when it's not neccesary is something user wouldn't expect, so it's un-intuitive.

Personally, I would prefer consistency no matter what revision is operated on, which doesn't involve conditionally changing the working copy to a parent. Additionally, I don't think there are many other complaints about this, so perhaps most other users do not share the same opinion that this behavior is un-intuitive.

Many people are not oriented towards evolution/development and just accept suboptimal status quo (and some are even able to fight for it) 🙂

This is why my proposal is to create a new flag which allows you to disallow creating new commits implicitly. If this is the desired behavior of most users, users will start to use this flag, and there will be more feedback about changing the default.

Yes, why do the right thing, when you can do wrong one and wait for somebody to yell at you 😀

Maybe jj should ask (or make that configurable) if it should update the current commit, or move the changes to the new one, but implicitly creating new commits is not a good default the same way as you wouldn't want your editor to behave that way...

[kuchta]

Well, when I think about it, maybe it's not a bad idea to make that configurable, since if there would be some watch mode (or editor extension that watches for changes) in the future that would create new commit after each save, that could also be interesting workflow for some projects...