FR: Is it possible to make the auto anonymous working copy commit optional and configurable?

[cloudhan]

Is your feature request related to a problem? Please describe.
Currently the working copy will be automatically committed to an anonymous commit, this is drastically different from git workflow. With jj, it becomes a subtractive process on making commit, wheraes the git one is additive.

Describe the solution you'd like
Make it configurable.

Additional context
This create some friction of my adopting jj. Before I fully evaluate it, I don't want to fully commit to it yet. I am currently using git-branchless and it works like a charm, and I heard that jj provides some advance feature, I want to give it a try, but just I don't want to change my workflow.

[cloudhan]

Welp, the skip^n mgr said if you commit credential to the repo, then you are not eligible for promotion in the next fiscal year 😅. As jj and git branchless have already automated many process, the subtractive part is extremely suspicious to me.

[martinvonz]

Did you considering trying jj in a throw-away clone of your repo?

Besides the risk of persisting credentials, is your main concern that you'll be wasting disk space?

To answer your question directly: I don't think it makes much sense to add a config option. That would be equivalent to having a config option to git that prevented committing. I.e., you would have a read-only repo then.

[cloudhan]

I mean, I want to

jj new ...
# edit <some file>
jj add <some file> # update the current commit manually, 
                   # this effectively disable the anonymous working copy commit completely,
                   # and leave it to user. Whether updating the current commit or a staging area is an open question.
# no split needed, move on

Manually add file to the commit I am working on, instead of automatical updating.

jj new
# edit <some file> and the working copy is tracked automatically
jj split ... # and then move on

is your main concern that you'll be wasting disk space

not main concern, but disk space wasting is definitly a thing.

[martinvonz]

You can emulate the git workflow by replacing git checkout X by jj new X -m "staging area" && jj new and git add -p by jj squash -i. That might be an interesting way to transition from git. I think you'll quickly get tired of having a separate staging area, but who knows.

[cloudhan]

More precisely speaking, it is not about reverting to the git workflow and staging area, it is about additive vs subtractive. How to achieve the additive workflow is another question. And the title is misleading.

With additive workflow, I selectively add my change to the repo. The unfinished files and dirty working directory is not managed by jj.

With substractive workflow. I selectively pick my change from the managed working copy commit with split.

[thoughtpolice]

This is morally the equivalent, I guess, of running --ignore-working-copy with every command. But I think this request might go a little too "against the grain" of the current design philosophy in several important ways, and making it a feature is unlikely.

The additive-vs-subtractive metaphor is helpful, but there are more subtle consequences to the "snapshot" model we use today that go beyond simple workflow changes. There are large design ramifications. For instance, in your example, what if you ran jj new again after you edited the file but before you ran jj add? Today jj simply takes a snapshot first and then switches states trivially. But now the "dirty working tree" case needs to be handled specifically, because the file you modified won't be snapshotted. Do you reject all uses of jj new until the file is recorded? Only allow it for commits that don't conflict? What if a conflict does happen? These need to be addressed. There are probably many such cases with every command, now. (To be fair those problems already exist when you do --ignore-working-copy, but now they're much more important as persistent UX for users!)

Effectively, this re-introduces the concept of the "working copy" as a distinct object from a "commit" in the data model. But the snapshot model we use today instead makes these equivalent, so that the working copy is just a commit; we consider that a good thing! Overall, many operations that would leave the tree in potentially "unsafe" or indeterminate states with other tools are trivially safe with jj thanks to the snapshot model. I've come to appreciate the simplicity of it. I don't think we should encourage people to shy away from it; we probably have to accept (and tell users!) that some workflow fundamentals have to change.

said if you commit credential to the repo, then you are not eligible for promotion in the next fiscal year 😅.

FWIW, this is definitely a huge problem. :) The biggest problem with this is that:

• jj doesn't garbage collect the operation log, so those commits hang around
• In the future, with some kind of source control server, you may send those changes to the upstream system when a snapshot happens

I don't know what to think about number 2, but number 1 is definitely something that people are aware of, though a tracked issue to implement oplog gc currently escapes me and might not be filed. But it's been discussed in relatively recent memory...

[martinvonz]

As @thoughtpolice said, it'd be a huge change to allow a dirty working copy, and it would add a lot of complications that we have avoided by letting the working copy be represented by a commit. So I'm going to close this issue as infeasible. The GC issue is #12, btw.

More precisely speaking, it is not about reverting to the git workflow and staging area, it is about additive vs subtractive. How to achieve the additive workflow is another question. And the title is misleading.

With additive workflow, I selectively add my change to the repo. The unfinished files and dirty working directory is not managed by jj.

With substractive workflow. I selectively pick my change from the managed working copy commit with split.

I think there may be less difference between the workflows than you think. I actually don't agree with the "additive vs subtractive" distinction. Whether you use git add -p or jj split, you select some of the changes you've already made. Maybe it's mostly about a mindset? Try to not think of "committed" as meaning "done". I would recommend going through the tutorial if you haven't already. Maybe it's less different in practice than you fear.