cli: status: only scan through mutable changes to find conflicts

[edre]

Fixes #3628
Verified manually

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[martinvonz]

Thank you! If we're going to get this into 0.17.1, the commit should be based on that commit and we should do a merge into main. I think that means I'll at least temporarily need to enable "Merge by merging" or whatever it's called in GitHub.

[martinvonz]

Thank you! If we're going to get this into 0.17.1, the commit should be based on that commit and we should do a merge into main. I think that means I'll at least temporarily need to enable "Merge by merging" or whatever it's called in GitHub.

And we'll of course need to bump the version numbers too. So maybe we should create a new branch for this instead. I don't know how people normally do this with GitHub. Anyway, please don't merge this for now even if you get approval. And could you also make sure it's based on v0.17.0? Thanks

[edre]

Rebased to tag 0.17.0

[edre]

Alternatively I could merge this to main, and you could locally jj duplicate to whatever release branch works for you.

[martinvonz]

Alternatively I could merge this to main, and you could locally jj duplicate to whatever release branch works for you.

I don't think that helps much other than for getting it more quickly to people who build from source on the main branch because the duplicated commit will have the same problem as your current commit has. I don't have any special permissions (though I own the repo so I could temporarily grant myself special permissions if we don't have a better solution).

[yuja]

nit: Since immutable_heads() is a user expression, .evaluate_programmatic() can't be used anymore.

[thoughtpolice]

Thank you! If we're going to get this into 0.17.1, the commit should be based on that commit and we should do a merge into main. I think that means I'll at least temporarily need to enable "Merge by merging" or whatever it's called in GitHub.

And we'll of course need to bump the version numbers too. So maybe we should create a new branch for this instead. I don't know how people normally do this with GitHub. Anyway, please don't merge this for now even if you get approval. And could you also make sure it's based on v0.17.0? Thanks

TBH, in this case I'd suggest that we just do "trunk based development" and just merge this, then immediately cut another release from main directly. We fixed barely anything in the past 7 days. I think it's completely OK to rollup the current changes on top of 0.17.0 into an 0.17.1; there's not really much risk in that.

[martinvonz]

TBH, in this case I'd suggest that we just do "trunk based development" and just merge this, then immediately cut another release from main directly. We fixed barely anything in the past 7 days. I think it's completely OK to rollup the current changes on top of 0.17.0 into an 0.17.1; there's not really much risk in that.

We discussed this a bit on Discord. We made the changes directly on the release branch and then merged into to main branch this time. We can have a separate discussion about instead cherry-picking to the release branch in the future.