What can cause jj git fetch not to update tracked branches? How can I recover from that?

[BatmanAoD]

Any idea what is happening here? My guess is that this has something to do with having a stale working copy at one point, and not properly recovering from it. But I would have expected the main branch to be updated even if the working copy was ignored; and from the "concurrent modification detected; resolving automatically" message, and the absence of subsequent "working copy is stale" messages, I thought I no longer had a stale working copy.

❯ jj new main
Error: Failed to snapshot the working copy
Caused by: New file /Users/kstrand/workspace/infrastructure/AWSCLIV2.pkg of size ~35.5MiB exceeds snapshot.max-new-file-size (1.0MiB)
Hint: Increase the value of the `snapshot.max-new-file-size` config option if you
want this file to be snapshotted. Otherwise add it to your `.gitignore` file.

❯ jj --ignore-working-copy new main

❯ jj status
Error: The working copy is stale (not updated since operation a8f0fe6475da).
Hint: Run `jj workspace update-stale` to update it.
See https://github.com/martinvonz/jj/blob/main/docs/working-copy.md#stale-working-copy for more information.

❯ jj workspace update-stale
Reset the working copy parent to the new Git HEAD.
Error: Failed to snapshot the working copy
Caused by: New file /Users/kstrand/workspace/infrastructure/AWSCLIV2.pkg of size ~35.5MiB exceeds snapshot.max-new-file-size (1.0MiB)
Hint: Increase the value of the `snapshot.max-new-file-size` config option if you
want this file to be snapshotted. Otherwise add it to your `.gitignore` file.

❯ git ls-files AWSCLIV2.pkg

❯ rm AWSCLIV2.pkg

❯ jj new main
Concurrent modification detected, resolving automatically.
Working copy now at: wuslowps 4d008c86 (empty) (no description set)
Parent commit      : wssoytqn 43945a97 main | (empty) Merge branch '<elided>' into 'main'

❯ jj status
The working copy is clean
Working copy : wuslowps 4d008c86 (empty) (no description set)
Parent commit: wssoytqn 43945a97 main | (empty) Merge branch '<elided>' into 'main'

❯ jj git fetch
Nothing changed.

❯ git checkout main
Previous HEAD position was 2d64948f <elided>
Switched to branch 'main'
Your branch is behind 'origin/main' by 32 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

❯ git pull
Updating 43945a97..5e609f2a
Fast-forward
....

[BatmanAoD]

Any ideas on this?

[martinvonz]

I don't know what the problem might be. Maybe there's some hint in jj branch list main?

@torquestomp, does this sound like the problem you mentioned in a meeting?

[ebensh]

I hit a weird issue potentially similar to this today; my repo (origin) is a fork of another gitlab repo (upstream). I had a MR open and our CI automation failed to merge after approval. A colleague with merge rights closed the MR, reopened it, and merged it themselves.

This created an odd state on my next jj git fetch --all-remotes - the same jj revision ID (is this the right term?) was pointing at two different git commits - one for main@origin, one for main@upstream.

I noticed in my GitLab that my fork was marked as "two commits behind, one commit ahead" of upstream - despite the "ahead" commit being identical to the one that had been merged upstream, something about the closing and reopening disassociated the revision/MR, or maybe created a second identical commit on the upstream with a new ID... something like this.

I wasn't able to successfully resolve it with jj abandon on the old commit from my branch, nor by escaping to git and force pushing the commit I thought I'd need on my fork. I wound up just deleting my fork entirely in GitLab and reforking the upstream repo, which naturally resolved the issue.

I'm not sure it's exactly the same case, but wanted to point it out. jj branch list main from the previous comment was actually what helped me find the revision conflict to begin with - otherwise I wouldn't have understood the revision conflict. (Thanks @martinvonz !)