Represent current commit's description as a file

[evmar]

I was thinking about issue #6540, which is about where to place the temporary file used for editing a commit's description, and I thought of what is maybe a nice solution: don't use temporary files at all.

jj's big idea (for me) is that the working directory is "the same as" a commit, where editing a file updates the commit. We could do the same with the commit's description:

1. make jj edit X update some .jj/.../description file with the current commit's description
2. make other jj commands that refresh the current commit (e.g. how jj st etc. scan the workspace and integrates any file changes) also check this description file and use it to update the current commit as well

Now commands like jj describe would just open your editor pointed at that file, and do the same refresh when you exit.

This would also mean you could use the normal tooling on your commit description:

• command-line tools that munge text (e.g. a script could echo ... > .../description to add a footer to it)
• you could keep it open in your editor to update as you take notes
• (etc. etc., probably some more ideas here)

[PhilipMetzger]

Thanks for the idea. I have pondered on something like that for jj run (#1869) for a while, since it is also partially needed until we can call jj within its invocations. I don't think keeping the file around for all snapshots is beneficiary, since that would require special handling in the already critical filewalking/snapshotting code.

[evmar]

I also considered this impact on the snapshotting code, but I think it's effectively one more file's worth of state to track. So in a multi-thousand file "big" repository the number of files goes from multi-thousand to multi-thousand plus one.

[PhilipMetzger]

I also considered this impact on the snapshotting code, but I think it's effectively one more file's worth of state to track. So in a multi-thousand file "big" repository the number of files goes from multi-thousand to multi-thousand plus one.

In a multi-thousand file "big" repository, a custom working-copy implementation should be used since the local_working_copy already is a local maxima. So this change will mostly impact Git backend/FOSS users which feel the impact of each new matcher in the local_working_copy implementation.

@ilyagr should also be interested in pursuing something like this, since he wanted to support conflicted commit descriptions at some point.

[joyously]

I like this idea, but is it workable in an async environment?

[yuja]

Even if we had description objects in the store, we'll need a temporary file as an editor UI, I think. jj describe can edit descriptions from multiple revisions, which is really nice.

[arxanas]

Besides the jj run use-case (for which I'm a fan of being able to modify the commit description in this way), storing it in the commit more directly means you can also do three-way merge on the commit's description, not only the contents. I think Gerrit at least represents the commit description in the UI as if it were a file subject to merging (and it might actually store it in the Git object store; I don't know).

[jennings]

This reminds me of matklad's idea for a Magit-like LSP.