4 ms·

Here's my take on the one-liner that I use via a `git tidy` alias[1]. A few points: * It ensures the default branch is not deleted (main, master) * It does no

Here's my take on the one-liner that I use via a `git tidy` alias[1]. A few points: * It ensures the default branch is not deleted (main, master) * It does not touch the current branch * It does not touch the branch in a different worktree[2] * It also works with non-merge repos by deleting the local branches that are gone on the remote git branch --merged "$(git config init.defaultBranch)" \ | grep -Fv "$(git config init.defaultBranch)" \ | grep -vF '*' \ | grep -vF '+' \ | xargs git branch -d \ && git fetch \ && git remote prune origin \ && git branch -v \ | grep -F '[gone]' \ | grep -vF '*' \ | grep -vF '+' \ | awk '{print $1}' \ | xargs git branch -D [1]: https://github.com/fphilipe/dotfiles/blob/ba9187d7c895e44c350f8e74d8bfbaaadbe97d6a/gitconfig#L55 https://github.com/fphilipe/dotfiles/blob/ba9187d7c895e44c35... [2]: https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree

rubinlinux 7mo ago
The use of init.defaultBranch here is really problematic, because different repositories may use a different name for their default, and this is a global (your home directory scope) setting you have to pre-set. I have an alias I use called git default which works like this: default = !git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@' then it becomes ..."$(git default)"... This figures out the actual default from the origin.
- fphilipe 7mo ago
  I have a global setting for that. Whenever I work in a repo that deviates from that I override it locally. I have a few other aliases that rely on the default branch, such as “switch to the default branch”. So I usually notice it quite quickly when the value is off in a particular repo.
- jeffrallen 7mo ago
  This is a great solution to a stupid problem. I work at a company that was born and grew during the master->main transition. As a result, we have a 50/50 split of main and master. No matter what you think about the reason for the transition, any reasonable person must admit that this was a stupid, user hostile, and needlessly complexifying change. I am a trainer at my company. I literally teach git. And: I have no words. Every time I decide to NOT explain to a new engineer why it's that way and say, "just learn that some are master, newer ones are main, there's no way to be sure" a little piece of me dies inside.
  - nicoburns 7mo ago
    Why does your company not migrate to one standard? Github has this functionality built in, and it's also easy enough to do with just git. I'm personally a huge fan of the master-> main changejus5t because main is shorter to type. Might be a small win, but I checkout projects' main branches a lot.
    - Griffinsauce 7mo ago
      It's extremely obvious that "main" is more ergonomic. It's sad that we're so resistant to change (regardless of how valid you think the initial trigger was)
      - DangitBobby 7mo ago
        The miniscule (and still arguable, not obvious) "ergonomics" improvement was not and will never be worth the pain.
  - lazyasciiart 7mo ago
    No, actually, zero people 'must admit' that it was a stupid, user hostile and needlessly complexifying change. I would say any reasonable person would have to agree that a company which didn't bother to set a standard for new repos once there are multiple common options is stupid, user hostile and needlessly complexifying. And if the company does have a standard for new repos, but for some reason you don't explain that to new engineers....
    - 1718627440 7mo ago
      There was only a single standard before, so there was no reason why a company should make any company specific standard. The need for companies to make a standard only exists, since the master to main change, because now there are two standards.
      - Timwi 7mo ago
        I would argue there is still only one standard and it's main.
- suralind 7mo ago
  It's so funny. After seeing your comment I thought I must have this only to realize I already do: https://github.com/artuross/dotfiles/blob/main/home/dot_config/git/includes/aliases https://github.com/artuross/dotfiles/blob/main/home/dot_conf...
tonymet 7mo ago
This is a good one you should contribute it to git extras.

rubinlinux 7mo ago

The use of init.defaultBranch here is really problematic, because different repositories may use a different name for their default, and this is a global (your home directory scope) setting you have to pre-set. I have an alias I use called git default which works like this: default = !git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@' then it becomes ..."$(git default)"... This figures out the actual default from the origin.

fphilipe 7mo ago
I have a global setting for that. Whenever I work in a repo that deviates from that I override it locally. I have a few other aliases that rely on the default branch, such as “switch to the default branch”. So I usually notice it quite quickly when the value is off in a particular repo.
jeffrallen 7mo ago
This is a great solution to a stupid problem. I work at a company that was born and grew during the master->main transition. As a result, we have a 50/50 split of main and master. No matter what you think about the reason for the transition, any reasonable person must admit that this was a stupid, user hostile, and needlessly complexifying change. I am a trainer at my company. I literally teach git. And: I have no words. Every time I decide to NOT explain to a new engineer why it's that way and say, "just learn that some are master, newer ones are main, there's no way to be sure" a little piece of me dies inside.
- nicoburns 7mo ago
  Why does your company not migrate to one standard? Github has this functionality built in, and it's also easy enough to do with just git. I'm personally a huge fan of the master-> main changejus5t because main is shorter to type. Might be a small win, but I checkout projects' main branches a lot.
  - Griffinsauce 7mo ago
    It's extremely obvious that "main" is more ergonomic. It's sad that we're so resistant to change (regardless of how valid you think the initial trigger was)
    - DangitBobby 7mo ago
      The miniscule (and still arguable, not obvious) "ergonomics" improvement was not and will never be worth the pain.
- lazyasciiart 7mo ago
  No, actually, zero people 'must admit' that it was a stupid, user hostile and needlessly complexifying change. I would say any reasonable person would have to agree that a company which didn't bother to set a standard for new repos once there are multiple common options is stupid, user hostile and needlessly complexifying. And if the company does have a standard for new repos, but for some reason you don't explain that to new engineers....
  - 1718627440 7mo ago
    There was only a single standard before, so there was no reason why a company should make any company specific standard. The need for companies to make a standard only exists, since the master to main change, because now there are two standards.
    - Timwi 7mo ago
      I would argue there is still only one standard and it's main.
suralind 7mo ago
It's so funny. After seeing your comment I thought I must have this only to realize I already do: https://github.com/artuross/dotfiles/blob/main/home/dot_config/git/includes/aliases https://github.com/artuross/dotfiles/blob/main/home/dot_conf...

tonymet 7mo ago

This is a good one you should contribute it to git extras.