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!
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)
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.
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...
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.
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:
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`
< 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.
37 comments
[ 2.8 ms ] story [ 91.0 ms ] thread2019: https://wiki.hyperledger.org/display/INTERN/Git+signing+with...
2020: https://wiki.hyperledger.org/display/INTERN/Git+Commit+Signi...
That's worked really well for me
https://github.com/foriequal0/git-trim
At most you’ll have trouble running the right version (rare nowadays, unlike in pre-v1 days)
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.
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.
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
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:
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.The merged branches part is missing.
> 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.