Avoiding divergent changes arising from merge bot branches

[TeofilC]

Merge bots like mergify like to create temporary branches in git repos in order to run CI.

When running jj git fetch these get added to the repo and then lead to divergent changes, since a commit exists both in my stack of work, and cherry-picked onto this branch. (I'm not sure why jj identifies these as the same change, but it does).

I can resolve this by calling jj abandon on mergify's copy of the change, but ideally I would like to handle this automatically.

Is it possible to just ignore a glob of branches when doing jj git fetch?
If I could do that then I could just ignore all of mergify's wip branches and I wouldn't encounter this issue. Or maybe there is a different better way to handle this.

[jennings]

When running jj git fetch these get added to the repo and then lead to divergent changes, since a commit exists both in my stack of work, and cherry-picked onto this branch. (I'm not sure why jj identifies these as the same change, but it does).

That surprises me, I wouldn't expect jj to assign the commit in the new branch the same change ID. I don't suppose you have a public example?

[TeofilC]

I've spent some time trying to reproduce this in a fresh repository with a copy of our mergify rules.
And I'm struggling to get this behaviour to trigger. I'm suspicious that the following is how what I originally saw happened:

• I put a change A into the merge queue
• Mergify creates a new branch with A and merges trunk into it
• I modify A locally maybe by rebasing it over trunk
• I run jj git fetch. I now have a divergent change

If this is the sequence of events then I think everything is happening correctly.

I'm going to wait for this to happen again and see if I can understand how it came about

[michaelpj]

There is something a bit dissatisfying here? Some other person (here a CI system) can make a temporary branch that includes you change, and then boom, suddenly it's immutable. Given that the jj workflow generally seems to encourage mutating changes and then force-pushing the branches (from git's perspective), it's awkward to be blocked from doing that.

[martinvonz]

I think part of the answer is to just accept that divergent changes are fine. At least for immutable commits, there's nothing you can do about them, and there's little harm in them existing. We have #5800 and #5850 about making them not look so scary in jj log etc.

[TeofilC]

A potential workaround here if we don't want to see the mergify branches is to use git fetch directly and use negative refspecs. See: https://git-scm.com/docs/pull-fetch-param

This would allow you to tell git to not grab certain patterns of branches by the default, and you can exclude mergify/*.

Then you can do git fetch && jj git import rather than jj git fetch and you'll get everything but the branches you've excluded. Of course this requires a colocated repo

[michaelpj]

Possibly related: #6038