Use git shortcuts with a new version, overriding old - linux

Question

I'm using git on a shared hosting plan which runs a Linux distribution. Because it's shared, I don't have access to sudo. The machine already has git version 1.7.1 installed in /usr/bin/, but this version is rather prehistoric at this point. I've already used make install to get the current version 2.14.1, which is in ~/git-2.14.1/. As detailed by this answer, I can access the correct version of git from the command line like so:
$ git --version
git version 2.14.1
which was a simple change to the $PATH variable, in the ~/.bash_profile, so I can use git just fine.
I have a list of shortcuts in my ~/.gitconfig file that make git much faster for me to use:
[alias]
co = checkout
st = status
ci = commit
... etc etc etc
When I invoke these (e.g. git st), I get the results from the wrong version of git. It goes back to 1.7.1. If I type out the full command (e.g. git status), it uses the correct version of git.
I also have these commands in my ~./bashrc:
git () {
case "$*" in
st* ) shift 1; command ~/git-2.14.1/git status "$#" ;;
* ) shift 1; command ~/git-2.14.1/git "$#" ;;
esac
}
Which I have source-ed since writing.
I have also tried:
alias git="~/git-2.14.1/git"
To no avail.
Is there a work-around that would allow me to use these shortcuts with my preferred version of git? I am imagining a way to hide the config file from the other version by redirecting the pointer to a different location, but I have no knowledge of the existence of any such pointer.
Alternatively, is there a way to totally disable the previous version of git without root access?

Answer 1

When I invoke these (e.g. git st), I get the results from the wrong version of git. It goes back to 1.7.1
That is not what I see in my Ubuntu session.
I have in my .gitconfig
[alias]
st = status
br = branch
v = !git version
That means I type git v, to check git version (which is the same as git --version).
If I change my PATH to a new compiled Git, I do see a different version.
vonc#VONC:~/gits$ echo $PATH
/usr/local/bin:/usr/bin:/bin
vonc#VONC:~/gits$ which git
/usr/bin/git
vonc#VONCAVN7:~/gits$ git v
git version 2.13.0
vonc#VONC:~/gits$ export PATH=~/gits/v2.14.0/bin:$PATH
vonc#VONC:~/gits$ git v
git version 2.14.0

Answer 2

Here's what I found. If I took out the alias section of the .gitconfig, the aforementioned shell wrapper function worked. If I removed that and restarted the ssh connection, nothing worked (as expected).
I found, with help from this answer, that there is a magical GIT_EXEC_PATH variable which tells git where to find tools like git-add, git-commit, git-status, et. al.. Uncommenting my alias section of the .gitconfig file and using
$ export GIT_EXEC_PATH=/path/to/my/new/git's/executables/
made it possible to use the aliases in the .gitconfig file. For me the path that worked was the same folder as I installed into: ~/git-2.14.1.You can check the current value of GIT_EXEC_PATH with:
$ git --exec-path
/path/to/my/new/git's/executables/
Also, echo $GIT_EXEC_PATH works as well. My understanding is that git uses its aliases not through the instance of git which called git <alias>, but rather directly through the executables in it's exec path.
Note: for me,
$ git --exec-path=/path/to/my...
did not work, but if I understand correctly, this is the equivalent command.
TL;DR: add the path to the new executables (git-add, git-status, etc.) in your .bash_profile:
export GIT_EXEC_PATH=/your/path/