hartwork
detect and alert (or otherwise handle) when local branch is out of sync with remote
When the remote repo has branches that are not in sync with the local one, the tool gives a very clear warning:
Remote 'cabbey' is not up to date with 1 local branch(es):
- main
This will likely impair detection of merged branches for remote 'cabbey'.
Please consider getting it back in sync by running
$ git push cabbey main
and then invoking git-delete-merged-branches, again.
However when the opposite is true, you just get a warning and error from git and an overall failure:
warning: not deleting branch 'improve-encryption' that is not yet merged to
'refs/remotes/cabbey/improve-encryption', even though it is merged to HEAD.
error: The branch 'improve-encryption' is not fully merged.
If you are sure you want to delete it, run 'git branch -D improve-encryption'.
Deleted branch bye-render (was 30e49492767).
Deleted branch crop-vs-orientation (was 95b84c24f6d).
...
Error: Command 'git branch --delete bye-render crop-vs-orientation improve-encryption ...' returned non-zero exit status 1.
It would be nice if the tool could detect that this is going to happen and either omit those branches from the delete command and explain to the user that they are not in sync. (In my case there had been a last minute merge of main into the branch, which was then merged to main and pushed up to upstream, but was not pushed to my personal fork. I just did a git branch -D improve-encryption and re-ran the tool.)
Hi @cabbey for each branch we would need to do a git cherry against all existing remotes I suppose? That doesn't seem ideal, worth the runtime, worth the implementation effort. Any other ideas to detect this situation?
I don't think you would have to do quite that much. Assuming you have fetched the remote it should just be a matter of comparing what hash is used by refs/heads/foo and refs/remotes/target/foo. At least in the majority case where they match that should be fast. Some additional overhead maybe needed to understand WHY they don't match, as it could be either way around, either local or remote may have changes that the other doesn't, or worse: both. I'd think all three cases should be handled the same though... don't try to delete it on the remote side as it's potentially not what you compared to locally to determine if it was fully merged.