Cleanse squashed branches

[johngeorgewright]

The master-cleanse alias does not take in to account squashed branches ☹️

[joelparkerhenderson]

Thanks for the info. I'll read up about this. Do you have a solution in mind?

[joelparkerhenderson]

Here's information about squash merge automatic delete: https://stackoverflow.com/questions/43489303/how-can-i-delete-all-git-branches-which-have-been-squash-and-merge-via-github

There is no easy way to automate this, at least not completely. (Some special cases could be handled.) Instead, the best thing to do is to delegate this branch-deleting to the person whose pull request has been squash-merged. There are several good reasons for that:

• They are the only ones who can be sure the merge was done correctly.

• Suppose, for instance, that in order to squash-merge a series of six commits, the person who did the squash-merge had to, or chose to, change a few characters somewhere in a line or two, for some reason good or bad. That line or two means that the overall change in the final commit is different from the sum of the six changes in the six commits.

• But is the overall result correct? If you did not do any of the changes yourself, how will you know?

• They are the only ones who know if they intend to keep developing on that branch.

• Just because the six commits on feature/tall were squashed into one commit added to devel does not mean that feature/tall is all done. They may have several more commits to add; they may want to rebase feature/tall onto devel again, dropping the six squashed commits in favor of the one six-commit-squash, but keeping another three commits they are about to add.

There are probably some more cases. These may all be rare; they may never occur in your project; but the point here is that branch feature/tall is their branch, not your branch, so they—whoever they are—should be the ones deleting it when it's done.

Note that when you pick up feature/tall you have your own Git rename it to origin/feature/tall (assuming your remote is named origin). If you are experimenting with it, and git checkout feature/tall, your Git makes a copy for you. Once they delete feature/tall and you run git fetch origin --prune, your Git deletes your origin/feature/tall. So now the problem is simpler and can be automated: find branches whose "upstream" is gone, and delete those. (The one line script in this answer has some minor flaws; see the comments; a fancier one would use git for-each-ref and look up each branch's upstream setting with git rev-parse, but that's probably overkill.)

[johngeorgewright]

Thanks @joelparkerhenderson.

use git for-each-ref and look up each branch's upstream setting with git rev-parse, but that's probably overkill.

In that same post is an example of using git for-each-ref which does pretty much what you suggest:

git checkout -q master && \
git for-each-ref refs/heads/ "--format=%(refname:short)" \
| while read branch
  do mergeBase=$(git merge-base master $branch) && \
      [[ $(git cherry master $(git commit-tree $(git rev-parse $branch^{tree}) -p $mergeBase -m _)) == "-"* ]] && \
      git branch -D $branch
  done

Seems to work for me. I'm trying to figure out if there are any times this might not be sufficient. Maybe, for now, it could be it's own alias? And if so, what would it be called?

[joelparkerhenderson]

Yes it can be. What are some name ideas?

In parallel, I'll be changing the name of the "master-cleanse" because most tech companies are changing from using "master" to "main" because the language is more inclusive.

[johngeorgewright]

As it seems to do more than just clean squashed branches (in fact it's probably like a very thorough main-cleanse), I guess it could be something like main-cleanse-refs?