Should sync have a --prune flag?

[claytonrcarter]

When fetching remotes, I almost always use fetch --prune to remove remote branches that have been deleted. I then have an alias¹ to delete local branches that were tracking those remote branches. (In my case, such deletions nearly always indicate that the MR/branch was merged.) This is so common for me that I'm surprised that we don't support this in sync, and I'm left wondering if I've missed something in my workflow that would make this easier. 😄

1. Is there a better way to delete merged branches (w/ or w/o branchless) than git fetch --prune && git prune-local?
2. Is sync supposed to be deleting merged branches, and I'm doing something that prevents that? (It is hiding the merged commits from the smartlog, but the branch refs are now pointing to the merge commit on main where that branch was merged.)
3. If we add a --prune flag, should sync also just delete the local tracking branches? Or should/could that be behind another flag (eg --prune for remote branches and --prune-local for remote and local branches)?

Footnotes

1. 'prune-local' is aliased to '!git branch -vv | awk '/: gone]/{print $1}' | xargs git br -d' ↩

[arxanas]

• I usually rely on Git configuration to automatically prune branches, like in https://stackoverflow.com/questions/18308535/automatic-prune-with-git-fetch-or-pull, rathee than git sync itself.
• If the commits have been rebase-merged into the main branch, then git sync should automatically delete associated branches when it rebases the same local commits onto main, sees that they've already been applied upstream, and then deletes the branches.
  • If your local branch has advanced compared to the remote branch, then this behavior won't trigger since the local branch points to a commit that wasn't deduplicated.
  • Currently, if the commits are merged or squash-merged, the local branches won't be cleaned up (which could be improved).
  • Does one of the above situations apply to you?