I found a useful Git one liner buried in leaked CIA developer docs

13 hours ago (spencer.wtf)

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/ba9187d7c895e44c35...

[2]: https://git-scm.com/docs/git-worktree

  • 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.

    • 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.

    • 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.

      2 replies →

I have a cleanup command that integrates with fzf. It pre selects every merged branch, so I can just hit return to delete them all. But it gives me the opportunity to deselect to preserve any branches if I want. It also prunes any remote branches

    # remove merged branches (local and remote)
    cleanup = "!git branch -vv | grep ': gone]' | awk '{print $1}' | fzf --multi --sync --bind start:select-all | xargs git branch -D; git remote prune origin;"

https://github.com/WickyNilliams/dotfiles/blob/c4154dd9b6980...

I've got a few aliases that integrate with fzf like an interactive cherry pick (choose branch, choose 1 or more commits), or a branch selector with a preview panel showing commits to the side. Super useful

The article also mentions that master has changed to main mostly, but some places use develop and other names as their primary branch. For that reason I always use a git config variable to reference such branches. In my global git config it's main. Then I override where necessary in any repo's local config eg here's an update command that updates primary and rebases the current branch on top:

    # switch to primary branch, pull, switch back, rebase
    update = !"git switch ${1:-$(git config user.primaryBranch)}; git pull; git switch -; git rebase -;"

https://github.com/WickyNilliams/dotfiles/blob/c4154dd9b6980...

  • > For that reason I always use a git config variable to reference such branches. In my global git config it's main

        $(git config user.primaryBranch)
    

    What about using git's own `init.defaultBranch`?

    I mean, while useless in terms of `git init` because the repo's already init'd, this works:

        git config --local init.defaultBranch main
    

    And if you have `init.defaultBranch` set up already globally for `git init` then it all just works

    • Hmm that might be nice actually. I like not conflating those two things, but as you say if the repo is already init'd then there's no chance it'll be used for the wrong purpose.

      In any case the main thrust was just to avoid embeddings assumptions about branch names in your scripts :)

  • You can pull another branch without switching first:

      git switch my-test-branch
      ...
      git pull origin main:main
      git rebase main

The main issue with `git branch --merged` is that if the repo enforces squash merges, it obviously won't work, because SHA of squash-merged commit in main != SHA of the original branch HEAD.

What tools are the best to do the equivalent but for squash-merged branches detections?

Note: this problem is harder than it seems to do safely, because e.g. I can have a branch `foo` locally that was squash-merged on remote, but before it happened, I might have added a few more commits locally and forgot to push. So naively deleting `foo` locally may make me lose data.

  • Depends on your workflow, I guess. I don't need to handle that case you noted and we delete the branch on remote after it's merged. So, it's good enough for me to delete my local branch if the upstream branch is gone. This is the alias I use for that, which I picked up from HN.

        # ~/.gitconfig
        [alias]
            gone = ! "git fetch -p && git for-each-ref --format '%(refname:short) %(upstream:track)' | awk '$2 == \"[gone]\" {print $1}' | xargs -r git branch -D"
    

    Then you just `git gone` every once in a while, when you're between features.

  • I recently revised my script to rely on (1) no commits in the last 30 days and (2) branch not found on origin. This is obviously not perfect, but it's good enough for me and just in case, my script prompts to confirm before deleting each branch, although most of the time I just blindly hit yes.

    To avoid losing any work, I have a habit of never keeping branches local-only for long. Additionally this relies on https://docs.github.com/en/repositories/configuring-branches...

  • Not just squash merges, rebase-merges also don't work.

    > What tools are the best to do the equivalent but for squash-merged branches detections?

    Hooking on remote branch deletion is what most people do, under the assumption that you tend to clean out the branches of your PRs after a while. But of course if you don't do that it doesn't work.

  • I have the same issue. Changes get pushed to gerrit and rebased on the server. This is what I have, though not perfected yet.

      prunable = "!f() { \
      : git log ; \
      target=\"$1\"; \
      [ -z \"$target\" ] && target=$(git for-each-ref --format=\"%(refname:short)\" --count=1 refs/remotes/m/); \
      if [ -z \"$target\" ]; then echo \"No remote branches found in refs/remotes/m/\"; return 1; fi; \
      echo \"# git branch --merged shows merged if same commit ID only\" ;\
      echo \"# if rebased, git cherry can show branch HEAD is merged\"  ;\
      echo \"# git log grep will check latest commit subject only.  if amended, this status won't be accurate\" ;\
      echo \"# Comparing against $target...\"; \
      echo \"# git branch --merged:\"; \
      git branch --merged $target  ;\
      echo \" ,- git cherry\" ; \
      echo \" |  ,- git log grep latest message\"; \
      for branch in $(git for-each-ref --format='%(refname:short)' refs/heads/); do \
       if git cherry \"$target\" \"$branch\" | tail -n 1 | grep -q \"^-\"; then \
        cr=""; \
       else \
        cr=""; \
       fi ; \
       c=$(git rev-parse --short $branch) ; \
       subject=$(git log -1 --format=%s \"$branch\" | sed 's/[][(){}.^$\*+?|\\/]/\\\\&/g') ; \
       if git log --grep=\"^$subject$\" --oneline \"$target\" | grep -q .; then \
        printf \"$cr  $c %-20s $subject\\n\"  $branch; \
       else \
        printf \"$cr  \\033[0;33m$c \\033[0;32m%-20s\\033[0m $subject\\n\"  $branch; \
       fi; \
      done; \
      }; f"
    

    (some emojis missing in above. see gist) https://gist.github.com/lawm/8087252b4372759b2fe3b4052bf7e45...

    It prints the results of 3 methods:

    1. git branch --merged

    2. git cherry

    3. grep upstream git log for a commit with the same commit subject

    Has some caveats, like if upstream's commit was amended or the actual code change is different, it can have a false positive, or if there are multiple commits on your local branch, only the top commit is checked

    • if you're using gerrit then you have the Change-Id trailer you can match against?

  • This is my PowerShell variant for squash merge repos:

        function Rename-GitBranches {
            git branch --list "my-branch-prefix/*" | Out-GridView -Title "Branches to Zoo?" -OutputMode Multiple | % { git branch -m $_.Trim() "zoo/$($_.Trim())" }
        }
    

    `Out-GridView` gives a very simple dialog box to (multi) select branch names I want to mark finished.

    I'm a branch hoarder in a squash merge repo and just prepend a `zoo/` prefix. `zoo/` generally sorts to the bottom of branch lists and I can collapse it as a folder in many UIs. I have found this useful in several ways:

    1) It makes `git rebase --interactive` much easier when working with stacked branches by taking advantage of `--update-refs`. Merges do all that work for you by finding their common base/ancestor. Squash merging you have to remember which commits already merged to drop from your branch. With `--update-refs` if I find it trying to update a `zoo/` branch I know I can drop/delete every commit up to that update-ref line and also delete the update-ref.

    2) I sometimes do want to find code in intermediate commits that never made it into the squashed version. Maybe I tried an experiment in a commit in a branch, then deleted that experiment in switching directions in a later commit. Squashing removes all evidence of that deleted experiment, but I can still find it if I remember the `zoo/` branch name.

    All this extra work for things that merge commits gives you for free/simpler just makes me dislike squash merging repos more.

  • Mine's this-ish (nushell, but easily bashified or pwshd) for finding all merged, including squashed:

        let t = "origin/dev"; git for-each-ref refs/heads/ --format="%(refname:short)" | lines | where {|b| $b !~ 'dev' and (git merge-tree --write-tree $t $b | lines | first) == (git rev-parse $"($t)^{tree}") }
    

    Does a 3-way in-mem merge against (in my case) dev. If there's code in the branch that isn't in the target it won't show up.

    Pipe right to deletion if brave, or to a choice-thingy if prudent :)

  • What if you first attempted rebases of your branches? Then you would detect empty branches

I've had essentially that - if a bit fancier to accept an optional argument as well as handle common "mainline" branch names - aliased as `git lint` for a while:

    [alias]
        lint = !git branch --merged ${1-} | grep -v -E -e '^[*]?[ ]*(main|master|[0-9]+[.]([0-9]+|x)-stable)$' -e '^[*][ ]+' | xargs -r -n 1 git branch --delete

so:

    git pull --prune && git lint

sits very high in my history stats

The Git command is whatever, pretty basic and stuff i have done forever but i am glad i clicked because ended up going down the rabbithole of the Wikileaks it was sourced from

Some unhinged stuff there. Like the CIA having a project called "Fine Dining" which was basically a catalog of apps that could be put on a USB drive to hide malicious code.

A case officer picks a cover app from a list of 24: VLC, Chrome, Notepad++, 2048, Breakout. Plug in the USB. Cover app opens. Exfiltration runs silently behind it. Target walks back in and the officer can just say "oh was just playing some games on this machine"

  • How is that unhinged? Sounds like pretty normal spy craft?

    Like unhinged was everything to do with MKULTRA which eventually became just randomly drugging people's coffee with LSD.

If something this natural requires several lines of bash, something is just not right. Maybe branches should go sorted by default, either chronologically or topologically? git's LoC budget is 20x LevelDBs or 30% of PostgreSQL or 3 SQLites. It must be able to do these things out of the box, isn't it?

https://replicated.wiki/blog/partII.html

  • I used to think this but spending some time learning about xargs (hell even for loops) makes me feel like this is trivial enough to stuff somewhere.

    Lots of people have mentioned awkward use cases where decisions have to be made. A built in command would have to confront those and it might not be easy

  • "too many lines of bash" and "lines of code" seem like very strange metrics to use to form these types of opinions.

I currently have a TUI addiction. Each time I want something to be easier, I open claude-code and ask for a TUI. Now I have a git worktree manager where I can add/rebase/delete. As TUI library I use Textual which claude handles quite well, especially as it can test-run quite some Python code.

  • how do you trust the code claude wrote? don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?

    • I'm not GP, but I have backups, plus I always make sure I've committed and pushed all code I care about to the remote. I do this even when running a prompt in an agent. That goes for running most things actually, not just CC. If claude code runs a git push -f then that could really hurt, but I have enough confidence from working with the agents that they aren't going to do that that it's worth it to me to take the risk in exchange for the convenience of using the agent.

    • > how do you trust the code claude wrote?

      If that's something you're worried about, review the code before running it.

      > don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?

      I think you might want to not run untrusted programs in an environment like that, alternatively find a way of start being able to trust the program. Either approaches work, and works best depending on what you're trying to do.

      6 replies →

    • I push my branches daily, so I wouldn't lose that much work. If it breaks then I ask it to fix it.

      But I do quickly check the output what it does, and especially the commands it runs. Sometimes it throws all code in a single file, so I ask for 'good architecture with abstractions'.

      3 replies →

    • I assume that whatever I type can be also flawed and take precautions like backups etc

    • It's a git repo. What's sort of mess-ups are you worried about that you can't reflog your way out of (or ask claude code to fix)? It's certainly possible to lose uncommitted work, but once it's been committed, unless claude code goes and deletes .git entirely (which I've had codex do, so you'd better push it somewhere), you can't lose work.

  • Can you explain TUI? I have never heard this before

  • The amount of little tools I'm creating for myself is incredible, 4.6 seems like it can properly one/two shot it now without my attention.

    Did you open source that one? I was thinking of this exact same thing but wanted to think a little about how to share deps, i.e. if I do quick worktree to try a branch I don't wanna npm i that takes forever.

    Also, if you share it with me, there's obviously no expectations, even it's a half backed vibecoded mess.

    • I’ve been wanting similar but have instead been focused on GUI. My #1 issue with TUI is that I’ve never liked code jumps very smooth high fps fast scrolling. Between that and terminal lacking variable font sizes, I’d vastly prefer TUIs, but I just struggle to get over those two issues.

      I’ve been entirely terminal based for 20 years now and those issues have just worn me down. Yet I still love terminal for its simplicity. Rock and a hard place I guess.

  • That sounds like a complete waste of time and tokens to me, what is the benefit? So each time you do something, you let Claude one shot a tui? This seems like a waste of compute and your time

    • They said each time they want something to be easier, not each time they do something. And they didn’t mention it has to be one-shot. You might have read too quickly and you’ve responded to something that didn’t actually exist.

    • On the contrary. Once these tools exist they exist forever, independently of Claude or a Claude Code subscription. IMO this is the best way to use AI for personal use.

    • Now that I think about it, if Claude can put most useful functions in a TUI and make them discoverable (show them in a list), than this could be better than asking for one-liners (and forgetting them) every single time.

      Maybe I'll try using small TUI too.

I have something similar, but open fzf to select the branches to delete [1].

    function fcleanb -d "fzf git select branches to delete where the upstream has disappeared"
        set -l branches_to_delete (
            git for-each-ref --sort=committerdate --format='%(refname:lstrip=2) %(upstream:track)' refs/heads/ | \
            egrep '\[gone\]$' | grep -v "master" | \
            awk '{print $1}' | $_FZF_BINARY --multi --exit-0 \
        )

        for branch in $branches_to_delete
            git branch -D "$branch"
        end
    end

[1]: https://github.com/jo-m/dotfiles/blob/29d4cab4ba6a18dc44dcf9...

So effectively "I just discovered xargs"? Not to disparage OP but there isn't anything particularly novel here.

  • This feels like gatekeeping someone sharing something cool they've recently learned.

    I personally lean more towards the "let's share cool little productivity tips and tricks with one another" instead of the "in order to share this you have to meet [entirely arbitrary line of novelty/cleverness/originality]."

    But each to their own I suppose. I wonder how you learned about using xargs? Maybe a blog-post or article not dissimilar to this one?

    • I don't think there's anything wrong with sharing something cool, even if it's trivial to other people. The problem is framing a blog post with "ooh this was buried in the secret leaked CIA material".. and then the reader opens it to find out it's just xargs. It feels very clickbaity. Akin to "here's one simple trick to gain a treasure trove of information about all the secret processes running on your system!!" and it's just ps.

      1 reply →

    • No I agree with you. This whole aura of "well IIIII knew this and YOUUUUU didnt" needs to die. I get that it's sometimes redundant and frustrating to encounter the same question a few times... but there's always new people learning in this world, and they deserve a chance to learn too.

      Why do people constantly have to be looking for any way to justify their sense of superiority over others? Collaborative attitudes are so much better for all involved.

  • And they have to learn that from cia?

    That says so much about the generation we are in, just don’t go to school but learn math from mafia

  • Lots of negative sentiment on your comment, but I was going to write the same. Hopefully AI won’t make us forget that good command line tools are designed to be chained together if you want to achieve something that’s perhaps too niche as a use case to make it into a native command. It’s worth learning about swiss army utilities like xargs that make this easy (and fun)

  • It's cool that it comes from CIA, and someone who doesn't know about xargs may just learn something new. What is not to like?

  • Seriously, this seems like someone in awe of xargs. Maybe its the Bell Labs in me but this is boilerplate stuff.

I use this alias:

    prune-local = "!git fetch -p && for branch in $(git branch -vv | awk '/: gone]/{if ($1!=\"\*\") print $1}'); do git branch -d $branch; done"

1. Fetch the latest from my remote, removing any remote tracking branches that no longer exist

2. Enumerate local branches, selecting each that has been marked as no longer having a remote version (ignoring the current branch)

3. Delete the local branch safely

Much more complicated than necessary. I just use

git branch | xargs git branch -d

Don't quote me, that's off the top of my head.

It won't delete unmerged branches by default. The line with the marker for the current branch throws an error but it does no harm. And I just run it with `develop` checked out. If I delete develop by accident I can recreate it from origin/develop.

Sometimes I intentionally delete develop if my develop branch is far behind the feature branch I'm on. If I don't and I have to switch to a really old develop and pull before merging in my feature branch, it creates unnecessary churn on my files and makes my IDE waste time trying to build the obsolete stuff. And depending how obsolete it is and what files have changed, it can be disruptive to the IDE.

I keep a command `git-remove-merged`, which uses `git ls-remote` to see if the branch is set up to track a remote branch, and if it is then whether the remote branch still exists. On the assumption that branches which have had remote tracking but no longer do are either merged or defunct.

https://gist.github.com/andrewaylett/27c6a33bd2fc8c99eada605...

But actually nowadays I use JJ and don't worry about named branches :).

We all have something similar, it seems! I stole mine from https://stackoverflow.com/questions/7726949/remove-tracking-....

I also set mine up to run on `git checkout master` so that I don't really have to think about it too hard -- it just runs automagically. `gcm` has now become muscle memory for me.

  alias gcm=$'git checkout master || git checkout main && git pull && git remote prune origin && git branch -vv | grep \': gone]\'|  grep -v "\*" | awk \'{ print $1; }\' | xargs -r git branch -D'

  • Same using a git alias rather than shell, and without the network bits, it just cleans up branches which have an upstream that has been deleted:

        '!f() { git branch --format '%(refname:short) %(upstream:track,nobracket)'  | awk '$2~/^gone$/{print $1}'  | xargs git branch -D; }; f'

I've had this command as 'git drop-merged' for a few years now (put as a script in your path named git-drop-merged:

  #!/bin/sh
  git branch --merged | egrep -v "(^\*|master|main|dev)" | xargs --no-run-if-empty
  git branch -d

IIRC, you can do git branch -D $(git branch) and git will refuse to delete your current branch. Kind of the lazy way. I never work off of master/main, and usually when I need to look at them I checkout the remote branches instead.

    DEFAULT_BRANCH=$(git remote show origin | sed -n '/HEAD branch/s/.*: //p')

    git branch --merged "origin/$DEFAULT_BRANCH" \
      | grep -vE "^\s*(\*|$DEFAULT_BRANCH)" \
      | xargs -r -n 1 git branch -d

This is the version I'd want in my $EMPLOYER's codebase that has a mix of default branches

Speaking of user friendliness of git UI. I am working on a revision control system that (ideally) should be as user friendly as Ctrl+S Ctrl+Z in most common cases. Spent almost a week on design docs, looking for feedback (so far it was very valuable, btw)

https://replicated.wiki/blog/partII.html#navigating-the-hist...

  • Have you tried Jujutsu? If you want to make a better VCS, your baseline should be that, in my opinion, because it already deals with a lot of the Git pain points whilst be able to read and publish to Git repositories.

    • The idea of using git as a blob storage and building entire new machinery on top is definitely a worthy one. At this point though, the de-facto baseline is no doubt git. If git as a store withstands the abuse of jj and jj becomes the industry standard, then I would agree with you. Also, at that point they may drop git backend entirely just because of price/performance discrepancy. git is overweight for what it does, if they make it do only the bottom 20%, then things will get funny.

      Still, many oddities of git are inevitable due to its underlying storage model, so it makes sense to explore other models too.

What's wrong with just deleting the whole folder and clone repo and whatever branch you're interested in? In any case it's not an urgent thing. You don't have to do this mid-work, you can wait until you push most stuff and then rm && git clone.

The only case in which this wouldn't work is when you have a ton of necessary local branches you can't even push to remote, which is a risk and anti-pattern per se.

  • because of my precious stash? but also the repo is huge, the clone takes 10 minutes? And all the other branches...

    • doesn't your precious stash deserve an external folder or remote branch, in any case? the local repo is always a risk, so many things can ruin it. also, you only need to clean up like once a year, it's by definition a rare operation. A ton of branches doesn't grow overnight.

You could solve the original problem statement using just the part of the script that lists unmerged branches

I sometimes convert old branches to tags. So they don't show up in the list of branches, but I never lose any branches by accident.

All those "merged" workflows only work, if you actually merge the branches. It doesn't work with a squash merge workflow.

edit: I delegate this task to a coding agent. I'm really bad at bash commands. yolo!

This looks loosely like something already present in git-extras[1].

    [1]: https://github.com/tj/git-extras/blob/main/Commands.md#git-delete-merged-branches

I use

    #!/bin/sh
    
    git checkout main
    git fetch --prune
    git branch | grep -v main | xargs --no-run-if-empty git branch -D
    git pull

Save that next to your git binary, call it whatever you want. It's destructive on purpose.

I have an image of running his command, 'ciaclean', and a black van turnes up with a bunch of agents in coveralls, brandishing rolls of polyethylene sheeting and drums of acid.

I use this PowerShell variant:

    function Remove-GitBranches {
        git branch --merged | Out-GridView -Title "Branches to Remove?" -OutputMode Multiple | % { git branch -d $_.Trim() }
    }

`Out-GridView` gives you a quick popup dialog with all the branch names that supports easy multi-select. That way you get a quick preview of what you are cleaning up and can skip work in progress branch names that you haven't committed anything to yet.

Or don't go crazy making branches in the first place.

Have a merge workflow which deletes the branch right there.

This is the same thing as `git rebase-update`, available in Chrome's `depot_tools`, which deletes merged branches.

Beyond that, this is just OP learning how `xargs` works.

Anyone else "vibe git-ing” lately? I just ask Claude Opus to clean it up and it does really well. Same for build commands and test harnesses.

  • It does a pretty good job, but I still don't completely trust it with keys to the kingdom.

    I have replaced my standard ddg of, "git <the thing i need>" with asking Claude to give me the commands I need to run.

I've had this in my ~/.bash_aliases for awhile:

  alias git-wipe-merged-branches='git branch --merged | grep -v \* | xargs git branch -D'

Trying to remember where I got that one, as I had commented the following version out:

  alias git-wipe-all-branches='git for-each-ref --format '%(refname:short)' refs/heads | grep -v master | xargs git branch -D'

The git plugin in oh-my-zsh has an alias for this: gbda

It also has one for squash-merged branches: gbds

Very useful I've been using them for years

I needed that exact functionality and Claude code and ChatGPT consistently showing this same exact combo CLI receipt with the simple prompt "how to do use CLI to remove merged branch locally."

  • It's hardly a profound insight. If you're fluent at the command line, xargs enables all sorts of conveniences.

I don't delete branches, I just work with the top several most recently modified.

  • How to list those? Is there a flag for git branch to sort by recently modified?

    (not on my computer right now to check)

    • This isn't exactly the same but I've been using git-recent [0] (with `gr` alias) for many years. It sorts branches based on checkout order (which is what I usually need when switching between branches) and allows to easily choose a branch to checkout to.

      [0] https://github.com/paulirish/git-recent

    • I do `gb` (probably "git branch" when I set that up) which apparently is an alias to `git for-each-ref --sort=-committerdate refs/heads/ --format='%(refname:short)' | tac`, displays a list with the latest changed branch at the bottom. Remove the `| tac` for the reverse order.

      1 reply →

I’ve been using something similar for years with Nushell.

git branch | lines | where ($it !~ '^*') | each {|br| git branch -D ($br | str trim)} | str trim

If you squash your PR before merging, then this alternative worked really well for me:

  git fetch --prune && git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D

  • Almost identical to mine, but you've got smarter awk use: `git prune origin && git branch -vv | grep 'origin/.*: gone]' | awk '{print $1}' | xargs git branch -D`

    I think I probably copied this from Stack Overflow close to a decade ago. Seems like a lot of people have very similar variations.

Dont most git instances, like github, delete branch after a PR was merged, by default?

I am not sure under what usecases, you will end up with a lot of stale branches. And git fetch -pa should fix it locally

  • `--prune` will delete your local copies of the origin's branches (e.g. `origin/whatever`). But it won't delete your local branches (e.g. `whatever` itself). So PRs that you've worked on or checked out locally will never get deleted.

  • In Github it needs to be explicitly configured (Settings > General > Delete head branches after merging), Gitlab is the same.

    A lot of my developer colleagues don't know how git works, so they have no idea that "I merged the PR" != "I deleted the feature branch". I once had to cleanup a couple repositories that had hundreds of branches spanning back 5+ years.

    Nowadays I enforce it as the default project setting.

  • > Dont most git instances, like github, delete branch after a PR was merged, by default?

    By default, I don't think so. And even if the branch is deleted, objects can still be there. I think GitLab has a "Clean stale objects" thing you can trigger, I don't seem to recall ever seeing any "Git Maintenance" UI actions on GitHub so not sure how it works there.

> Since most projects now use main instead of master…

I see that even the CIA, a federal government office, has not fully used DEI approved, inclusive language yet :-)

  • The leaked material from which this came was described as being from 2017, which makes that the latest this could have been written - GitHub only changed the default for new repos in October of 2020, and there had only been consensus building around the switch for a couple of years beforehand.

I recently let copilot create a document with a few helpful git commands and that particular one was the one it came with as solution for exactly this case.

I cleanup branches interactively with a few lines of bash, which takes a bit more time but is less likely to destroy active work.

Wait, why would the update for the silly master->main change be swapping the excluded regex instead of just excluding both?

grep + xargs ... in other words, we're finally back at good old standard svn workflows

I want to point out explicitly that .git config supports aliases, so in .gitconfig put an [alias] section, and in that you can put ciaclean = "!alias ciaclean='git branch --merged origin/main | grep -vE "^\s(*|main|develop)" | xargs -n 1 git branch -d'"

so then it's `git ciaclean` and not bare `ciaclean` which imo is cleaner.

honestly my go to is kind of similar, but I prefer using --format vs. straight grep. just feels like the plumbing is cleaner out of the box:

    git branch --merged origin/main --format="%(refname:short)" \ | grep -vE "^(main|develop)$" \ | xargs -r git branch -d

that said... pretty hilarious a dev was just like "uhh yeah ciaclean..." curious what... other aliases they might have??

I've used this for about 10 years now. Pretty sure it was a widespread way of doing it before any CIA leak.

I work with GitHub, so this oneliner relly helps me out. It also doesn't rely on grep, since --format have all you need:

    git branch --format '%(if:equals=gone)%(upstream:track,nobracket)%(then)%(refname:short)%(end)' --omit-empty | xargs --verbose -r git branch -D

It deletes all the branches for which remotes were deleted. GitHub deletes branches after PR was merged. I alias it to delete-merged

i once used ai to generate a command doing the exact same thing.

git branch -vv | grep ': gone\]' | awk '{print $1}' | xargs -n 1 git branch -D

I use `master` in all my repos because I've been using it since forever and it never has once occurred to me "oh shit I better change it to `main` this time in case `master` may offend somebody some day. Unfortunately, that's the last thing on my mind when I'm in programming mode. Now that everything is `master`, maybe it is just a simple git command to change it to `main`. But, my fear is it'll subtly break something and I just don't have enough hours left in my life to accept yet unknown risk that it'll cost me even more hours, just to make some random sensitive developer not get offended one day.

  • Also, git's "master" branch is named after a master recording or master copy, the canonical original from which duplicates are made. There is literally no reason for it be offensive except for those who retroactively associate the word with slavery.

  • At Meta, when this mass push for the rename happened across the industry, a few people spent nearly the full year just shepherding the renaming of master to main, and white box/black box to allowlist/blocklist.

    This let them claim huge diff counts and major contributions to DEI and get promos.

  • Im just tuning out of the whole master vs main discussion. I use whatever is the default branch name of my current project OR what git init gives me. When / if git init produces a default branch named main, i'll use that.

  • In current times, there will be more people offended that some prefer to use "main" rather than "master", than people that will be offended if "master" is used

  • not on your mind, yet you found the time to write this comment

    are you sure this is about time/breaking and not "being told how to think"?

  • Haven't got enough hours to type fewer characters, but have got plenty of time to go karma-fishing about it on an almost barely tangentially relevant HN thread. Cool.

  • > But, my fear is it'll subtly break something and I just don't have enough hours left in my life to accept yet unknown risk that it'll cost me even more hours,

    Yeah, it's not like 99% of the world has already switched from master to main already (without any major problems) ...

    • You'll find CI/CD automation probably needs to be updated. (Triggering different actions when merges to the default branch happen, or perhaps just deployments.)

      These are the kinda local things that the parent was probably referring to.

[flagged]

  • agree, this just seems click-baity. if you're familiar with the UNIX Way, this is a one-liner you'd naturally write. CIA leaked docs mention and a blog post for this?

    • the Clandestine allure for clicks for sure but you know what - the comments have been pretty interesting.