Unclear how to land PR2 before PR1

[francois]

Using sl pr and the GitHub UI, is it actually possible to land patches in a different order than they were submitted? Let's imagine the following:

echo > foo
sl commit -m 'pr 1'
echo > bar
sl commit -m 'pr 2'
sl pr

Is it actually possible to merge / rebase / squash bar, without foo? Since the 2nd PR includes changes from the 1st one, it doesn't actually seem possible.

I'm kind of looking for something like a sl pr land --rev REV to make a later PR become public. sl ghstack land exists, but I haven't actually tried it yet. When doing that, will the PR be marked as merged / rebase / squashed or not?

Thanks for any help or clarification!

[francois]

I did a test against my scratch repository and ghstack land PR2 also lands PR1. Anyway, any clarifications would be welcome!

[evangrayk]

Generally the "happy path" for the stack workflow is to land patches in the order they're submitted (Not necessarily all at once). As you noted, since later patches depend on earlier ones, it is possible to hit merge conflicts which makes directly landing out of order tricky.

I think the easiest way is to re-arrange your stack locally with sl histedit and re-submit the whole stack with sl ghstack. This is where you'd be able to deal with merge conflicts, if any. Then the stacked PRs would appear in the new order that you'd like to land them in, which makes things easy to review / reason about again.

For a simpler case with just 2 PRs, you could also just rebase PR#2 off of PR#1 and onto main, then re-submit to "unstack" them into separate PRs. This is useful if the two changes don't depend on each other.

[bolinfest]

I agree with @evangrayk's suggestion, though we should cover something like this in our docs.

[francois]

Is the website/docs folder partially generated? I saw 06f447cd2c8ab3935851974e8819ecc4cf0b2656, which seems to imply that the files in website/docs/commands are automatically generated. Where can I help and add docs?

[bolinfest]

Note the files that have:

<!--
  @generated SignedSource<<34fa88c23169ca5927cb1077afb89311>>
  Run `./scripts/generate-command-markdown.py` to regenerate.
-->

So yes, these are generated from the docstrings in the code. Some are Python and some are Rust, so it's best to grep for them.

[jqphu]

Generally the "happy path" for the stack workflow is to land patches in the order they're submitted (Not necessarily all at once).

What's the typical way to land an entire stack that has been approved? i.e. is there an equivalent sl ghstack land for sl pr? Or is the best way just to go through each PR and land it manually.

(P.S. let me know if this isn't the right place to ask this question).

[evangrayk]

@jqphu after submitting multiple commits with sl pr, Sapling creates overlapping Pull Requests. The last PR in the stack contains all the commits in the stack. Merging this PR from the GitHub UI will thus include all the changes in the stack. One annoyance is that you currently have to manually mark the other PRs in the stack as closed.

(re: where to ask questions, it's ok to use issues for this, but we also have a discord channel: https://discord.gg/X6baZ94Vzh)

[jqphu]

@evangrayk

The last PR in the stack contains all the commits in the stack. Merging this PR from the GitHub UI will thus include all the changes in the stack.

Awesome! This is what I'm looking for. Thanks.

I've also joined the discord, I'll continue chatting there. Appreciate it :).