← Back to context

Comment by WickyNilliams

4 days ago

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

10 comments

WickyNilliams

Reply
lloeki  4 days ago

> 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

  • WickyNilliams  4 days ago

    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 :)

    • lloeki  4 days ago

      > I like not conflating those two things

      Fair enough!

      It simply occurred to me that if your `user.defaultBranch` is set to e.g `trunk` then presumably when you `git init` you also want it to create a `trunk` branch, ergo `init.defaultBranch` would be set to the same value, ergo... irrespective of naming, could they actually be the same thing?

      I can see a case for keeping them apart too though.

      1 reply →

MathiasPius  4 days ago

You can pull another branch without switching first:

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

  • hiccuphippo  4 days ago

    You can also rebase directly on the remote branch

        git fetch
    git rebase origin/main

    • 1718627440  3 days ago

      > git rebase origin/main

      When is that command actually useful? When you want to rebase it is likely because your local and the upstream branch have diverged, so this would just result in weird conflicts, because origin/main is no longer an ancestor to main. Wouldn't you want to use something like:

          git rebase $(git merge-base main origin/main) main --onto=origin/main

      or

          git rebase origin/main@{1} main --onto=origin/main

?

  • WickyNilliams  4 days ago

    Nice. That'll make things a bit smoother. Changing branches often trips me up when I would later `git switch -`.