`git-extras update` loses installation customizations

Found an issue when I was working with make install and git-extras update. The Makefile provides several customization variables, like $PREFIX, $BINPREFIX, $MANPREFIX, $DESTDIR, and so on. It also might exclude commands which were masked by aliases.

None of these customizations are recorded in the installed files, though. So they aren't picked up if you run git-extras update.

git-extras update does a simple check to detect the installation location.

  local bin=$(which git-extras)
  local prefix=${bin%/*/*}
  local orig=$PWD

  curl -s $INSTALL_SCRIPT | PREFIX="$prefix" bash /dev/stdin \

Here's what I think is going on now:
That $prefix it's detecting is actually $(PREFIX)$(BINPREFIX)/.. or $(DESTDIR)$(PREFIX)$(BINPREFIX)/... So if the user had supplied a $(BINPREFIX) in the original install, it will now get baked in to the main $(PREFIX) instead. And $(MANPREFIX) or any other relocations will be lost and revert to their default locations relative to the new $(PREFIX).

If the git-extras on your path is a symlink, the update installation will be dropped at the symlink location instead of the target, because it doesn't resolve symlinks to get the canonical path. (E.g., if I have a ~/bin/git-extras that is symlinked to the actual installation location, git-extras update will dump the new install right in ~.

The alias detection is also re-done at update time, which could modify the effective installation setup. Also, it looks like it doesn't uninstall the old version before installing the new version, so files or commands left over from a previous installation are still there, even if they were excluded by the later installation process, or didn't exist at all in the new version.

If you wanted to preserve the configuration choices, you could have the make install write out the effective values of the customizable variables (except for $(DESTDIR)) to something like an install-config.sh, include that file in the installation, and then source it inside git-extras update so it "remembers" all the choices from the prior install, and propagates them to the new one.

The symlink issue and lack of etc relocatability mean that git-extras update is broken inside Homebrew-managed installations, so we have disabled git-extras update in the Homebrew formula for git-extras.

I don't want to rain on anyone's parade here, but getting a self-hosted updater to work correctly under all platforms and package managers is really difficult and complicated. Maybe update should be removed? git-extras is a tool for git users, which means they're advanced users or developers. If you have a clone of the git-extras repo, doing the default installation update (which is all git-extras update supports) is as simple as git pull && make install. And the less-advanced users can probably get git-extras through a package manager like Homebrew or a Linux distribution.

Start with the Makefile and the git-extras update implementation, including the shown installation-location detection and install script invocation. Reproduce an install with customized PREFIX, BINPREFIX, MANPREFIX, or aliases, then run git-extras update and test a symlinked installation. Done means the project has a decided, validated approach that preserves or deliberately removes update support without leaving stale files.