deliciousinsights / git-clean-stale-local Goto Github PK

In some cases git will not know that a branch has been merged because your local version of the branch differs from the copy of the branch that was merged.

For example, let's say User A checked out Branch A, then User B checked out Branch A and rebased it to squash some of the commits into a larger commit, then User B merges Branch A into the default branch (let's say master) and deletes Branch A from your GitHub/GitLab repo. git on User A's machine doesn't think Branch A was merged into master because the commit SHA of the latest commit on User A's copy of Branch A doesn't match any of the commits that are now in master.

Unfortunately I'm not sure of a good way to fix this issue, short of adding a flag that would let you delete any branches without upstream counterparts (this would have the side effect of deleting local branches you haven't pushed yet, which isn't great).

When I run the script on macOS, it fails with:

sed: illegal option -- -
usage: sed script [-Ealn] [-i extension] [file ...]
       sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]
fatal: malformed object name

Could you maybe adopt it to macOS, as well?

@tdd Do you think that would be too dangerous to avoid unmerged stale branches cleanup?

git clean-stale-local [-n|--dry-run] [-u|--not-merged]

If our repository doesn't stick to the conventional origin remote or has many remote repositories, we are not able to stale clean branches for theses ones.

We should be able to use both:

git clean-stale-local [-n|--dry-run] (using origin as default) or git clean-stale-local [-n|--dry-run] <remote name>.

We may also consider adding a global option, targeting all remotes: git clean-stale-local [-n|--dry-run] [-a|--all]

I got stuck on this for a bit so I figure this might be useful to someone.

Git will not automatically update your local repository's default branch if the remote's default branch changes. So, if you change your default branch from master to develop, any copies of the repo cloned prior to the change will think master is the default branch, while any copies after the change will think develop is the default branch. This can cause the script to offer differing results depending on the machine you're on.

Solution: git remote set-head origin -a will update the branch that git considers the origin/HEAD to match the current default branch in the origin remote.

Source: Stack Overflow