Git: Deletion of merged branches taken beyond shell hacks | Hacker News Reader

Git: Deletion of merged branches taken beyond shell hacks

github.com

81 pointsspyc36 comments

Instead of re-packaging various git commands, I'd like to encourage people to contribute their ideas and skills to the actual git project. Send an email to git@vger.kernel.org, volunteer to help, and ask for advice and direction. Git needs you!

Maybe? We've had mentorships over the last couple of years trying to introduce some crypto features to Git, and they've been rebuffed.

What sort of features?

git-dids.

2019: https://wiki.hyperledger.org/display/INTERN/Git+signing+with...

2020: https://wiki.hyperledger.org/display/INTERN/Git+Commit+Signi...

Interesting hyperledger is backed by the Linux Foundation.. which is a front for large corporations to try to gain control over linux/FOSS/etc hmm

Good luck keep working on it!

Does this have any advantage over git trim?

That's worked really well for me

https://github.com/foriequal0/git-trim

Not so fancy, but a one-liner

  # Remove all local branches for which there is no remote
  git branch -r | awk '{print $1}' | egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | awk '{print $1}' | xargs git branch -D

> # Remove all local branches for which there is no remote

The merged branches part is missing.

I setup Github repos to automatically delete merged branches - in this case, the remote counterpart will be gone. There might be just the following missing to sync remove `origin/*` branches locally: `git fetch --prune`

Your newly created local branch might be gone as well.

The <() is a Bashism isn't it?

< is a redirect operator, the out of the item on the right is redirected to the in of the item on the left; () are just grouping operators like math to ensure that bit is self contained inline for the parser.

That might be a way to remember what it does, but I don't think that's how it works. Try doing `echo <(ls)` to see how it differs. Or, from the manpage:

> Process substitution is supported on systems that support named pipes (FIFOs) or the /dev/fd method of naming open files. It takes the form of <(list) or >(list). The process list is run with its input or output connected to a FIFO or some file in /dev/fd. The name of this file is passed as an argument to the current command as the result of the expansion. If the >(list) form is used, writing to the file will provide input for list. If the <(list) form is used, the file passed as an argument should be read to obtain the output of list.

Yes. See "Process Substitution" in "man bash". It works great, e.g. with diff (or meld):

  # diff -u <(echo $'one\ntwo') <(echo one)
  --- /dev/fd/63  2020-08-13 16:14:44.449379498 +0200
  +++ /dev/fd/62  2020-08-13 16:14:44.450379506 +0200
  @@ -1,2 +1 @@
   one
  -two

Gotcha. I wanted to know if it was POSIX compliant (it wasn't clear to me last time I looked it up).

Careful with "git branch -D" — it's a sharp knife.

Amazing timing! I was just auditing a colleague's (admittedly fairly well-written) shell script for this purpose. Nice to have this alternative.

why not just set `git config fetch.prune true`?

I don’t think this detects a branch that can be deleted after a squash merge to master

as long as the remote branch is deleted it does. Both github and gitlab can delete branch on merge

`git fetch --prune` only deletes remote-tracking branches (`refs/remotes/<remote>/<branch>`) but not local tracking branches (`refs/heads/<branch>`).

requires a python installation which brings a lot of stuff and new vulnerabilities... instead, see the other post about contributing straight to the git project

yeah it's been awhile since I've set up a python-ready environment, and trying to install this reminded me of the challenge of just getting to the expected starting point.

  $ pip install git-delete-merged-branches
  zsh: command not found: pip
  $ brew install pip
  Error: No available formula with the name "pip"
  pip is part of the python formula:
    brew install python
  $ brew install python
  ...
  OK
  $ pip install git-delete-merged-branches
  zsh: command not found: pip
  
  (look up how to install pip)
  $ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
  $ python get-pip.py
  WARNING: The scripts pip, pip2 and pip2.7 are installed in 
  '/Users/{me}/Library/Python/2.7/bin' which is not on PATH.
    Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  Successfully installed pip-20.2.2
  $ pip install git-delete-merged-branches
  zsh: command not found: pip
  (walk away)

I know there are solutions to all this, and it's mainly that I don't already have my $PATH set up the way that pip expects, etc, but really??

To be fair, python isn't the only language whose package management system is all but incoherent to folks who don't use python every day (and sometimes even to them!). npm is pretty rough to get setup too, and you run into a lot of issues similar to this.

I don’t think Node has trouble from the very first installation. A brew install will set you up with the latest version of both node and npm and they will work.

At most you’ll have trouble running the right version (rare nowadays, unlike in pre-v1 days)

This looks like brew issue more than python. `brew unlink python ; brew link python` may help you.

Homebrew has always been a hacky abomination. I get that it has made life easier for many people, but MacPorts is so much better. It's basically apt for Macs.

Homebrew used to unilaterally take over /usr/local, and do all sorts of unconventional things. A few years ago it started playing nicer, but at its core, it's eschewing time-honored conventions across the board.

One of the biggest things about Homebrew that is annoying is that it tries to reuse the stock MacOS libraries to avoid installing dependencies. So you end up with things built against ancient broken regex libs, etc.

MacPorts takes longer to install because it does things right. After you install all the MacPorts GNU libraries and utilities, you have a real Unix system that closely resembles Linux, which is what all the development tools expect.

Linux won the Unix war decades ago, whether anyone likes it or not. MacOS's BSD heritage is still causing pain for people today, especially since the core libraries are literally a decade out of date.

I've been a long time user of homebrew but lately I've been getting ticked off with the design choices its made.

In particular it will update things and break perfectly fine apps, and then make it hard to revert or downgrade.

I should look into macports or nix or one of the bsd package managers.

Same. Long ago, I finally got fed up with MacPorts when it insisted on building an entire Perl distribution as a dependency of a package I asked it to install. I found Homebrew, and I was very happy to learn that it offered a way install the same package with an optional flag that disabled the Perl dependency. It reminded me of Portage, the powerful package manager from Gentoo, so I migrated from MacPorts to Homebrew. I happily ran it out of ~/usr/brew for years, which allowed me to trivially clone my entire installation and experiment with potentially destructive operations like major database upgrades.

As Homebrew became more popular, it got more opinionated. The system that supports optional flags is effectively (if not officially) deprecated, and running it outside of /usr/local is unsupported. I recently tried to install a fresh Homebrew in a different custom location (/opt/brew). Many packages require building from source in this scenario, but I accepted that trade-off. I even begrudgingly accepting building an entire Python distribution as a dependency, because I really wanted everything to live under /opt/brew. But no matter what I tried, I could not get any of the modern postgresql packages to build. I burned several multi-hour sessions trying different versions of XCode CLT and alternate build flags. I really wanted to inquire how the maintainers actually manage to build the binary packages in the first place, but my impression from reading Github issues and mailing list posts is that I'd basically be told I was running an unsupported configuration, and that my only recourse would be to create my own formula and run it from a tap. But that finally was a bridge too far (been there done that), so I just gave up and let it make its mess in /usr/local.

I do think I understand why Homebrew has evolved this way. They are trying to support a huge userbase, and they're also subject to Apple's whims with regards to their development tools[1]. It's a massive project every year when new versions of macOS and XCode are released. They have to set limits to keep their sanity. It's just a bummer that I'm considering migrating again...

[1]: https://github.com/Homebrew/brew/pull/4334#issuecomment-4029...

EDIT: remove unnecessary bits; add forgotten link

And - somehow this installed Python 2 in 2020.

brew's fault. also, pip not being in the path is also brew's fault -- it installs in a non-default location so it doesn't conflict.

No, it doesn't. Parent commenter has been macOS stock Python instead of the Homebrew one.

Executables from the Python package aren't placed in $PATH because it clashes with the system-provided one. You have to explicitly add /usr/local/opt/python/libexec/bin in $PATH in order to use Homebrew python and pip. Homebrew warns you when you install packages that have these kinds of gotchas at the last stage of "brew install", so you could've avoided all the hassle if you actually read them. Looking at your command history, you've been using the system Python all along, not the Homebrew one.

Install-time warning message:

https://github.com/Homebrew/homebrew-core/blob/087008a4c8cfb...

Documentation referenced in the message:

https://docs.brew.sh/Homebrew-and-Python

Though not mandatory, you'd also want to add the following to your shell config so that you can have things you install with "pip --user" ready in $PATH:

    PATH+="$(/usr/local/opt/libexec/bin/python -c 'import site; print(site.getuserbase())')/bin"

This advice would also apply for Linux, but it's even more important for macOS/Homebrew because otherwise you'd end up messing up /usr/local.

this script just removed my local, never pushed, never merged branch

Which script are you referring to?

Reply on news.ycombinator.com