Missing documentation of `-o` flags supported on push

[RalfJung]

Reading #950 I learned that there is a -o base flag. It is not mentioned in the docs, so would be good if the docs could be completed. Are there more flags like that? -o merge is mentioned in the importing guide.

[RalfJung]

Generally the docs are pretty lite on how to push changes from a 'partial clone' back to the main repo, in particular for workflows where one does not have direct push access to the main repo but needs to create a PR instead. When I push to the proxy, will it try to directly push that to the underlying repo? That is obviously not what I want with a PR workflow.

[christian-schilling]

True we need to improve the docs here for sure.

Yes we do push to the main repo. So access is required. One way around that would be to do a github fork of the full main repo and do the PR there. The other alternative is what you are doing: Provide a partial repo to do the PR in. From there you have two options:

1. Merge the PR in the partial fork and periodically sync both ways (current plan for miri)
2. Set up some automation that will convert and merge every approved PR in the partial repo into the main repo. Then the main branch only needs one way sync. In theory this is better (lower integration delay) but you'll run into issues when those PR's don't pass the full repo CI.

You are in the middle of discovering the reasons why the longer term goal for the Josh project is to provide an alternative to github as a code review tool:
There are all kinds of issues with github PR workflows and UI, not just but in particular, when using partial repos.

[RalfJung]

One way around that would be to do a github fork of the full main repo and do the PR there.

That's what we will have to do the the syncs back to the rustc monorepo then.

you'll run into issues when those PR's don't pass the full repo CI.

Yeah there's no way the infra team will let us just push to the full repo. We need to go through the same queue and process as everyone else. This has nothing to do with github.

Would be nice if josh could be told 'the base is that other branch in that other repo over there', rather than having to have the base branch in the same repo as the one it will push to. Also forcing the use of the base even if the branch-to-push-to already exists would be useful.

[RalfJung]

There is something else going on with pushing that I do not understand... I am doing

git push http://localhost:8000/RalfJung/rust.git:subtree_prefix=75dd959a3a40eb5b4574f8d2e23aa6efbeb33573,src/tools/miri:/src/tools/miri.git -o base=master HEAD:mirisync-new

where mirisync-new does not exist yet. I am expecting a branch based off of the master in the remote, rust-lang/rust@ead49f0. But instead the newly created branch is based off of a commit almost 2 weeks in the past, rust-lang/rust@8e3b9bc. There's nothing wrong with that as far as I can see, it's a perfectly fine sync, but it seems completely random -- I don't have a mental model for why josh picked that particular commit. Is that described anywhere?

Further down the history (towards the tip), master does contain changes in the subrepo that have not been synced to the local repo yet (to what I pushed to josh). Under other circumstances josh likes to complain about that, but not here. But it's also not picking the last commit before such a change or anything like that, it's a seemingly random commit from inside rust-lang/rust#102165.

[christian-schilling]

That does indeed sound a bit strange. In particular since rust-lang/rust@8e3b9bc does not seem related to miri.
I will see if I can find an explanation tomorrow..

[RalfJung]

FTR, HEAD at that moment was rust-lang/miri@2093184.

[RalfJung]

Speaking of -o base, I noticed something odd. In my mental model of Josh, the following two are equivalent:

• Pushing a given subrepo commit to a remote branch that currently has commit X
• Pushing a given subrepo commit to a non-existent remote branch, and setting -o base=ref where ref currently has commit X

However, that is not what I am seeing in practice. I often see the first strategy fail with an error like

remote: josh-proxy
remote: response from upstream:
remote: To github.com:RalfJung/rust.git
remote:  ! [rejected]                JOSH_PUSH -> miri (non-fast-forward)
remote: error: failed to push some refs to 'github.com:RalfJung/rust.git'
remote: hint: Updates were rejected because a pushed branch tip is behind its remote
remote: hint: counterpart. Check out this branch and integrate the remote changes
remote: hint: (e.g. 'git pull ...') before pushing again.
remote: hint: See the 'Note about fast-forwards' in 'git push --help' for details.

but the second strategy still works fine in those situations. Is that expected behavior? This makes pushing a bit more annoying since I need to set up two branches (the base and the to-be-pushed-to branch). It might be worth at least documenting more clearly.

[mrtugicom]

We have a case and when finding existing issue before creating one, we found this is relevant issue.

We want to import another project that is updating overtime to our monorepo.
The documentation at https://josh-project.github.io/josh/guide/importing.html is straight forward enough to use git push josh $ref -o merge, but in our case :

We want to use another project with specific branch, for example v2-latest branch (not main branch)
Our monorepo project use main branch and dont have v2-latest branch like another project. So ...

when we use git push josh $ref -o merge from local checkout of v2-latest to monorepo main it didnt work because we dont have v2-latest branch on monorepo.

the question is, how to import another project's specific branch to monorepo's main branch?