git sync: Update upstreams of branches if upstreams are deleted

[mlcui-corp]

This is mainly to support the use of git cl as used in the Chromium project. git cl uses a "pull request (changelist) per branch" workflow, allowing for dependent pull requests by setting the "upstream" of a branch. In fact, depot_tools - the collection of commands that git cl is included in - has a command (git-rebase-update) which closely mimics the behaviour of git-branchless sync, and handles the following issue.

To show an example of the issue:

Setup commands

$ git sl
⋮
◆ c1bdb24 23m (ᐅ main) Add hello

$ git checkout --track -b cl1    
branchless: processing 1 update: branch cl1
branch 'cl1' set up to track 'main'.
Switched to a new branch 'cl1'
branchless: processing checkout

$ touch cl1 && git add cl1 && git commit -m "CL 1"
branchless: processing 2 updates: branch cl1, ref HEAD
branchless: processed commit: 287ab78 CL 1
[cl1 287ab78] CL 1
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 cl1

$ git checkout --track -b cl2
branchless: processing 1 update: branch cl2
branch 'cl2' set up to track 'cl1'.
Switched to a new branch 'cl2'
branchless: processing checkout

$ touch cl2 && git add cl2 && git commit -m "CL 2"
branchless: processing 2 updates: branch cl2, ref HEAD
branchless: processed commit: 3f986ba CL 2
[cl2 3f986ba] CL 2
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 cl2

$ git sw main
branchless: creating working copy snapshot
branchless: running command: git checkout main
Switched to branch 'main'
branchless: processing checkout
⋮
◆ c1bdb24 26m (ᐅ main) Add hello
┃
◯ 287ab78 1m (cl1) CL 1
┃
◯ 3f986ba 1m (cl2) CL 2

We have a main branch, one branch cl1 with main as upstream, and cl2 with cl1 as upstream.

$ git sl
⋮
◆ c1bdb24 26m (ᐅ main) Add hello
┃
◯ 287ab78 1m (cl1) CL 1
┃
◯ 3f986ba 1m (cl2) CL 2

$ git branch -vvv | cat
  cl2  3f986ba [cl1: ahead 1] CL 2
  cl1  287ab78 [main: ahead 1] CL 1
* main c1bdb24 Add hello

Let's say that cl1 was merged into upstream (main):

$ touch cl1 && git add cl1 && git commit -m "CL 1 (merged in)"
branchless: processing 2 updates: branch main, ref HEAD
branchless: processed commit: 1bccdd3 CL 1 (merged in)
[main 1bccdd3] CL 1 (merged in)
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 cl1

$ git sl
⋮
◇ c1bdb24 29m Add hello
┣━┓
┃ ◯ 287ab78 4m (cl1) CL 1
┃ ┃
┃ ◯ 3f986ba 4m (cl2) CL 2
┃
◆ 1bccdd3 5s (ᐅ main) CL 1 (merged in)

$ git branch -vvv | cat
* main 1bccdd3 CL 1 (merged in)
  cl2  3f986ba [cl1: ahead 1] CL 2
  cl1  287ab78 [main: ahead 1, behind 1] CL 1

Then, when doing a git sync, the branch cl1 disappears as it's merged in (as expected):

$ git sync
Attempting rebase in-memory...
[1/2] Skipped commit (was already applied upstream): 287ab78 CL 1
[2/2] Committed as: 1378396 CL 2
branchless: processing 2 updates: branch cl1, branch cl2
branchless: processing 2 rewritten commits
branchless: creating working copy snapshot
branchless: running command: git checkout main
Switched to branch 'main'
branchless: processing checkout
In-memory rebase succeeded.
Synced 287ab78 CL 1

$ git sl           
⋮
◆ 1bccdd3 40s (ᐅ main) CL 1 (merged in)
┃
◯ 1378396 9s (cl2) CL 2

but cl2 still has an upstream of cl1, which is now gone!

$ git branch -vvv | cat
  cl2  1378396 [cl1: gone] CL 2
* main 1bccdd3 CL 1 (merged in)

$ git sw cl2
branchless: creating working copy snapshot
branchless: running command: git checkout cl2
Switched to branch 'cl2'
Your branch is based on 'cl1', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)
branchless: processing checkout
⋮
◇ 1bccdd3 52s (main) CL 1 (merged in)
┃
● 1378396 21s (ᐅ cl2) CL 2

This is a feature request to update branch upstreams when git sync deletes branches - in this case, updating the upstream of cl2 to be main.

This also applies for chains of branches: for example, main is the upstream of cl1 which is the upstream of cl2 which is the upstream of cl3. If both cl1 and cl2 were applied upstream, cl3 should have an upstream of main after a git-branchless sync.

[arxanas]

Thanks for the suggestion. I'm a little bit surprised that the code review process works this way. If I understand correctly, cl1's upstream is main, and cl2's upstream is cl1? I think in Github/Gitlab/others, new branches are created such that cl1's upstream is the remote branch cl1 and cl2's upstream is the remote branch cl2.

Could this behavior be implemented by looking at all current branches, finding their nearest ancestor branches, and setting the upstream branch to that nearest ancestor? You might be able to solve this problem right now for yourself by adding a command like this to your git sync alias (except setting the upstream branch, rather than just printing it):

for branch in $(git query --branches 'draft () & branches()'); do
  # NB: might be empty if there is no previous branch:
  previous_branch=$(git query --branches "heads(branches() & ancestors($branch^))")
  echo "Previous branch of $branch is: $previous_branch"
done

[mlcui-corp]

Yes, your understanding is correct. Chromium's code review process is interesting - it uses Gerrit as a front-end, but its tooling (git-cl) diverges from the typical Gerrit workflow. If my understanding is correct, Gerrit doesn't have a typical remote-branch model (see Upload a Change in the Gerrit guide) - it uses a patch-based review model, and git-cl does the following as an abstraction on top of Gerrit:

• when uploading a PR, diffs the current branch with its tracking upstream and uploads that to Gerrit
• after uploading a PR, associates the newly-created PR with the branch, so re-uploading the PR updates the PR as expected
• I believe it uses the tracking upstream as the "parent commit" for the diff, which allows tracking dependent changes

I assume this is due to the legacy of Chromium's code review process (was previously using Rietveld instead of Gerrit), but lots of presubmits and checks are built into git-cl so Chromium developers must use it. It's not a bad system, especially as it allows for flexibility (it supports a rebase workflow OR a merge workflow, and allows for multiple commits per PR OR a single commit per PR) - but it requires maintaining branches with the correct (possibly local) upstream set.

Thanks for the query / revset pointers! That works if every branch only has one commit - which is the workflow which I'll probably adopt for this workflow - but breaks when branches might have multiple commits (as heads(x) uses immediate descendants). I've found a hacky workaround for it - only(x, x^) returns the "last" commit of x, so replace x with branches() & ancestors(BRANCH^) to get the "previous branch" of a given BRANCH.

[mlcui-corp]

Interestingly, it can possibly return multiple branches if multiple branches are pointing to the same commit - but this can be worked around with a | tail or | head.

I feel like this could probably be more robust than "re-calculate parent branches" - possibly by using a script which keeps a "branch to upstream" mapping before and after a git-branchless sync. I'll probably end up following this route.

Implementing this within git-branchless sync itself seems difficult, and is extra baggage to maintain in a big project just for Chromium developers. I initially assumed that other projects might have similar workflows, but from what you've mentioned it's probably a very niche use case.

[mlcui-corp]

For future readers - I'm currently using a modification of the aforementioned Bash script. This has been working pretty seamlessly - $previous_branch hasn't ever given me 0 or 2+ branches.

for branch in $(git query --branches 'draft () & branches()'); do
  previous_branch=$(git query --branches "only(branches() & ancestors($branch^), (branches() & ancestors($branch^))^)")
  git branch --set-upstream-to="$previous_branch" "$branch"
done