Surprising author of the first working copy

[InCogNiTo124]

Description

I am writing a codelab-like tutorial for jj on the basis of Steve's tutorial. For that I tried to make up a [email protected] author, to avoid using personal data. However, it seems that the first working copy commit is created with global metadata, and that changing the author before doing anything does not fix that.

Steps to Reproduce the Problem

mkdir -p /tmp/test
cd /tmp/test
jj git init
jj config set --repo user.name 'Code Lab' && jj config set --repo user.email '[email protected]'
jj log

Expected Behavior

$ (/tmp/test) jj log
@  nlylsuyy [email protected] 2024-07-07 00:35:56 41444201
│  (empty) (no description set)
◉  zzzzzzzz root() 00000000

Actual Behavior

$ (/tmp/test) jj log
@  nlylsuyy [email protected] 2024-07-07 00:35:56 41444201
│  (empty) (no description set)
◉  zzzzzzzz root() 00000000

(The username is an email address which is not supposed to be used for this repo. Subsequent commits, however, do use [email protected] mail address.)

Specifications

• Platform: arch rolling
• Version: 0.18.0 – tested with 0.19.0, too

[InCogNiTo124]

I presume it's the ~/.config/jj/config.toml file entry that drives this

[ilyagr]

I think the issue is that the commit is created by jj git init.

You can run jj describe --reset-author --no-edit to fix it. Another current workaround would be to run JJ_USER="Example User" [email protected] jj git init.

In principle, we could have jj reset the author for empty commits when the commit is changed. We considered something like that in #3906 , but we previously didn't have a use-case in mind when it would matter.

We could also potentially addjj config set --repo functionality to jj git init via options, so that it sets the options before the init and then writes a repo-wide config.toml.

[ilyagr]

Another option might be to have jj git init create a commit with no author and change the author when the commit is rewritten.

[emilazy]

In principle, we could have jj reset the author for empty commits when the commit is changed.

Yes, please (and the committer too). This trips me up whenever I set a per‐repo email address, which is fairly common and can only be done after cloning.

jj git init creating the commit without an author seems like it would work seamlessly if that was implemented.

[InCogNiTo124]

If it's a simple fix, I'd like to take a stab at this

[emilazy]

I think it shouldn’t be too hard; you could look at #3906 for inspiration. jj git init could also make the initial timestamp be the epoch, since the timestamp is already reset in the same case, which might be nice as it means it could give more reproducible results.

[yuja]

It wouldn't be hard, but might be a bit wonky. If you ran jj git init in existing directory (or made some working-copy changes), the initial snapshot could be attempted before setting up the correct user name.

Maybe we can add warning or hint if the author of the current working-copy commit doesn't match (and if description is empty)?

[scott2000]

In principle, we could have jj reset the author for empty commits when the commit is changed. We considered something like that in #3906, but we previously didn't have a use-case in mind when it would matter.

One issue with this approach is that it would only reset when the user actually changes something. If the user immediately looks at the log before changing anything in the working copy (which seems fairly likely if they just changed the config and want to see whether it worked), it would still show the old author and they might be confused. So maybe the warning would be less likely to cause confusion.

[InCogNiTo124]

Just throwing it out there, what about jj config set --repo commands resetting the working copy author? I can't see something obviously wrong with that approach

[ilyagr]

One issue with this approach is that it would only reset when the user actually changes something.

Good point. I'm not sure this is a fatal problem to the idea of changing the behavior of empty commits to address the problem of the issue (this is what I meant by referencing #3906), but it's certainly a downside.

Just throwing it out there, what about jj config set --repo commands resetting the working copy author?

Sorry to add to the confusion, but I don't like this idea as is. I wonder if it could be modified to something workable, though.

The problems are: 1) jj config set --repo does not modify any commits currently, and changing this seems like it would be unexpected and 2) this singles out the working copy commit in a way I don't like. What if more than one commit needs to be changed?

One possibility that comes to my mind would be for jj config set --repo to detect what commits have the old author and suggest a command to fix it. Currently, I think it would have to suggest running jj describe --no-edit --reset-author on each commit. In principle, we could make jj describe --no-edit accept a revset and then jj describe --no-edit --reset-author 'author("old-email")' would work.

[emilazy]

See also #3828 for the jj describe idea.

[InCogNiTo124]

One possibility that comes to my mind would be ofr jj config set --repo to detect what commits have the old author and suggest a command to fix it.

Currently, I think it would have to suggest running jj describe --no-edit --reset-author on each commit. In principle, we could make jj describe --no-edit accept a revset and then jj describe --no-edit --reset-author 'author("old-email")' would work.

SGTM, I'll try going in that direction.