jj icon indicating copy to clipboard operation
jj copied to clipboard

github reports "recent pushes" for branches that weren't changed after a `jj git push`

Open zygoloid opened this issue 3 years ago • 4 comments

Description

When checking out a repository on github and then performing jj git push, all branches seem to get pushed, even ones that have not changed. This causes github to report spurious "had recent pushes 2 minutes ago" notices for each branch.

Steps to Reproduce the Problem

  1. Fork some repository on github.
  2. Make a branch and push some changes, don't open a PR.
  3. Some time later, check out the fork with jj, make some changes unrelated to those branches, and then jj git push.

Expected Behavior

Unchanged branches are not touched on the server so github doesn't report any changes.

Actual Behavior

Github seems to believe every branch in the fork has changed, despite the head commit hash on the unchanged branches being the same.

Specifications

  • Platform:
  • Version:

zygoloid avatar Jul 02 '22 01:07 zygoloid

I wasn't able to reproduce this. If it's reproducible for you, can you share the output of jj branch list before and after the push (feel free to filter it down to the relevant branches)?

martinvonz avatar Jul 05 '22 00:07 martinvonz

I was not able to reproduce this by simply jj git pushing any more.

I was wondering if this had something to do with my previously having two remotes with the same URL, and indeed I was able to reproduce this by recreating that situation.

$ jj git remote add duplicate <URL of origin>
$ jj git branch list
branch-1-name: hash1 message1
branch-2-name: hash2 message2
branch-3-name: hash3 message3
$ jj git push --remote duplicate
[github reports a bunch of changes for branches that didn't change]
$ jj git branch list
branch-1-name: hash1 message1
branch-2-name: hash2 message2
branch-3-name: hash3 message3

The jj branch list output before and after the jj git push is identical -- same hashes and no per-remote info listed. FWIW, I then deleted the duplicate and that seemed to break things:

$ jj git remote remove duplicate
$ jj branch list
branch-1-name (deleted)
  @origin: hash1 message1
branch-2-name (deleted)
  @origin: hash2 message2
branch-3-name (deleted)
  @origin: hash3 message3

(Incidentally, noticed while undoing the above mess: the jj git remote remove command shows up in the op log, but the jj git remote add command does not.)

zygoloid avatar Jul 14 '22 23:07 zygoloid

I was wondering if this had something to do with my previously having two remotes with the same URL, and indeed I was able to reproduce this by recreating that situation.

Oh, that makes a lot of sense that it happens when you push to a duplicate remote. When you run jj git push --remote duplicate, jj will try to propagate the branches in your local repo to that remote. It doesn't check that the URL is the same as for another remote. I'm not sure what we should do about that. Comparing URLs is obviously not reliable.

(Incidentally, noticed while undoing the above mess: the jj git remote remove command shows up in the op log, but the jj git remote add command does not.)

Very observant :) The reason is that jj git remote add doesn't affect the "repo view" (basically what you can see in jj log), but jj git remote remove usually does because it will remove the remote branches recorded for the remote.

martinvonz avatar Jul 15 '22 00:07 martinvonz

One option is to simply always fetch from the remote before pushing. I don't know if that (or something equivalent) is how git avoids the problem. However, #293 makes me reluctant to do that at the moment.

martinvonz avatar Jul 15 '22 04:07 martinvonz