Dealing with squash and sync

[bcspragu]

Hello! In most of the repos I work on, the PR flow is something like:

1. Create a new branch
2. Write one or more commits
3. Create a PR + send for review
4. Write one or more commits in response to review
5. Squash and merge

I use a basic gh alias for step 5, which looks like: sm: '!gh pr merge --delete-branch --squash && git pull && git fetch -p', so I just run gh sm and it squash merges the PR, deletes the branch, and pulls in the latest changes.

This flow works excellent with git-branchless, the trouble comes after, as my next command is usually git sync to bring all the other branches up to date. If the branch I just merged was only a single commit, it correctly gets swept into the dustbin and disappears from git sl, but if it was multiple commits, I get a merge error, like:

Merge conflict (X file(s)) for <first commit from the pre-squash branch>

Which makes sense, as the squashed commit doesn't look like the first commit of that branch. I then manually run git hide -r <first commit of branch>, and all is well again.

My question: is there a magic incantation (or workflow change) I can do to make this issue go away? It's tedious having to manually 'clean up' old branches by typing commit hashes 10 times a day, and theoretically, the tooling could recognize that a branch is equivalent to a series of commits and appropriately remove them post-sync.

[claytonrcarter]

When you run git sm, do you have the branch checked out? If so, you may be able to add git hide -D 'stack()' to your alias to hide those commit and delete the branch. If you have other work stacked/based on of that PR branch, though, that would be too aggressive and you may want to try something like git hide -D 'main()..@'. On the other hand, if you instead call git sm my-pr-branch (I'm not familiar w/ the gh tool.) then you may be able to update your alias to something like !fn() { gh pr merge --delete-branch --squash "$1" && git pull && git fetch -p && git hide -D "main()..$1" && git move -s "children($1)" -d "main()" }; fn (ie define the alias as an immediately invoked shell function so that you can gain access to $1.) In any case, you may also need to change the order in which you prune branches with fetch -p.

tooling could recognize that a branch is equivalent to a series of commits and appropriately remove them post-sync.

That's interesting! There was some discussion of a similar topic in #283, and I think that the outcome was that such squashed "merge" commits were hard to detect w/o some combo of a workflow change and new logic in git-branchless. That was a while ago (before sync was added, I think) and I wonder if the project could now support some additional checks here. I'm thinking of something like "if a commit/branch cannot be applied during sync, check to see if the squashed product of the entire branch/stack has already been applied. If so, then this branch can be hidden and removed instead of moved; if not, then this is a legit merge conflict".

[bcspragu]

Thanks for the thorough answers (to both you and @arxanas). It took me a while to get back because I was waiting for a good candidate submitted PR to test this on. I think some combination of these two approaches is necessary. I like @arxanas's approach because it should just automagically work, but it does leave behind the original commits. An example:

$ git sl

◇ aaaaaaa 3d Some previous commit
┣━┓
┃ ◯ bbbbbbb 3d The branch, commit #1
┃ ┃
┃ ◯ ccccccc 3d The branch, commit #2
┃ ┃
┃ ● ddddddd 1d (ᐅ brandon/the-branch) commit #3
⋮
◇ eeeeeee 1h (main) Current latest on main

If I run git reset --soft $(git merge-base main HEAD) && git commit -m 'squash', that brings us to:

◇ aaaaaaa 3d Some previous commit
┣━┓
┃ ◯ bbbbbbb 3d The branch, commit #1
┃ ┃
┃ ◯ ccccccc 3d The branch, commit #2
┃ ┃
┃ ● ddddddd 1d commit #3
┣━┓
┃ ● fffffff 2s (ᐅ brandon/the-branch) squash
⋮
◇ eeeeeee 1h (main) Current latest on main

At this point, git sync will properly clean up ffffff/brandon/the-branch, but I've still got the other one left over to hide, and your git hide -D 'main()..@' should do the trick, I've just got to get the sequence/alias correct.

Thanks again!

[arxanas]

If I run git reset --soft $(git merge-base main HEAD) && git commit -m 'squash', that brings us to:

@bcspragu Instead, try git rebase -i and set all but the first to squash (or fixup). That way, you won't have the commits B, C, and D still in your commit graph, because git-branchless will process them as rewritten into the new single squashed commit. (It's also possible to do this non-interactively if necessary by modifying the commit messages with special directives; see the --autosquash option to git rebase.)

[claytonrcarter]

I finally reopened my PR for move --fixup, which should also help w/ cases where you want to squash commits. (And, you know, do so w/ one command and really fast 😄)

[arxanas]

The easiest way is probably to squash the commits in your PR locally, (force-)push the new PR contents to GitHub, and then do the merge (or squash merge) in GitHub, so that git-branchless can track the contents of the squashed commits. Then your git sync should do the right thing.

You could also try a tool like https://github.com/hartwork/git-delete-merged-branches, which might be able to detect the squash after the fact. It would be nice to have logic like that in git-branchless, but it's currently not implemented.