av st sync without rebase/fetch

[oleg-codaio]

It looks like av stack sync --no-fetch got removed recently:

Flag --no-fetch has been deprecated, please use av stack restack for offline restacking

If I create a commit at the end of a stack (or amend a commit) is it possible to push up the latest stack without fetching and rebasing all the way from the trunk? If I'm working on a stack in progress, I don't always want to keep rebasing it and triggering CI for the entire stack.

[draftcode]

Does av stack restack work as suggested in the message?

[steve-codaio]

I ran into this recently too. The issue is when you want the restack without fetching the trunk, but you do want to push the new branches. 'sync' is the only command that actually runs a push, but sync also always fetches

[draftcode]

Then, av stack submit (for pushing multiple branches) or av pr create (for pushing one branch) after av stack restack?

av stack sync's previous behavior's --no-fetch makes a weird state that, even though the GitHub API metadata indicates that "it's merged at this commit", that commit is not available locally.

[oleg-codaio]

av stack submit will create PRs for those branches. But I usually don't want to create any kind of PR until I've confirmed it will pass on CI (to avoid polluting the PR with force push updates). Ideally there would be a way to just repush the whole stack up.

The closest command I've found is to call av st for-each -- git push -f but it's not as efficient as av st sync used to be.

[draftcode]

OK. Then, let's add something. Either av stack sync or av stack restack.

[oleg-codaio]

Maybe av stack sync --no-trunk-rebase?

[draftcode]

The problem on that is that it's unclear what it does on the partially merged stacks. There are multiple possibilities.

1. Do not rebase the branches that are on top of merged branches. Leave them as-is.

   However, if this option is taken, probably there's no way to rebase those branches at all. Also, if you use a squash merge, this is going to be a problem since GitHub probably sees this as branch being stale.

   Correction: GitHub won't detect this branch being stale. Instead, the already merged commits appear on the children, so you'll see the diffs from the already merged PRs on this option.

2. Rebase onto a trunk's commit that includes the merged branches.

   Well... Even though the option itself says --no-trunk-rebase, it rebases onto trunk.

3. Rebase onto a trunk's remote tracking branch.

   Same as (2), but more up-to-date. This is anyway the current behavior.

On the other hand, adding --push option on av stack restack also has a problem since it doesn't know if a branch is merged or not. This will push the already merged branches again.

[draftcode]

Maybe making av stack sync to run rebase conditionally?

• If a stack is partially merged, rebase onto trunk's remote tracking branch. As described in my comment above, if a stack is merged partially, you'll need to rebase them in order to make the diff right.
• Otherwise, check if the current stack will make a merge conflict with the trunk. We can do a recursive merge on memory to detect if there's a conflict. If there's a conflict, prompt a user if they want to rebase.
• Other non-conflicting branches, leave them as-is.

We don't have to implement the second step for now, and change the av-cli behavior to rebase conditionally by default. Then, add --rebase-to-trunk option to always rebase all branches to trunk remote tracking branch.

With the second step implemented, av stack sync will detect when it's better to rebase to trunk (because there's a conflict). Until then, users need to manually check if there's a conflict and they need to decide if they should add --rebase-to-trunk option.

[draftcode]

v0.0.40 by default implements the logic described above. Closing this.