I apologize if this seems basic but I'm new to linux and not really sure how to proceed. My current git version is 1.7.1 and is located in /usr/bin/git but a newer version of git (1.8) is now available in /usr/src/git/bin/git. How do I make git use this version by default as opposed to the 1.7.1 version?
You have to make sure to call the right executable. This can ben done by explicitly calling /usr/src/git/bin/git instead of git. Of course this would be annoying to type all the time, so you can either make git an alias for that path by adding the line
alias git=/usr/src/git/bin/git
to your .bashrc, or add the directory /usr/src/git/bin to your binary search path by adding the line
export PATH="/usr/src/git/bin:$PATH"
To test that the other git installation searches for the core binaries in the right place, you can check the output of git --exec-path.
Related
How to install a specific version of git commit in Linux? When any program requests for the library it should take from the installation.
Eg:
The following version of wiringPi is required by one of my c++ program.
git://git.drogon.net/wiringPi
Version: 5edd177112c99416f68ba3e8c6c4db6ed942e796
Add a checkout statement after you clone?
Eg:
git clone git://git.drogon.net/wiringPi
git checkout 5edd177112c99416f68ba3e8c6c4db6ed942e796
Then you type the build and installation commands - if you want everything to use it, it probably needs to go in the default location. For the package you're looking at the documentation says it's:
./build
If you already have a version from a package manager (like apt you should remove that first - the README.md from the package you linked explains how to do this)
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?
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
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/
So I wanted to install some vim plugins using Vundle, I got everything set up, ran PluginInstall command and got this:
fatal: Unable to create temporary file: Result too large
I should mention that I have both git-bash and cygwin git package installed on my environment.
I did some googling and found that I shouldn't use windows version of git through cygwin, installed cygwin git package, tried again to no avail. Turns out even though I have installed the cyg pkg, cygwin is still using the git-bash one.
I tried manually pulling the plugin with cygwin's git version and it worked. So how do I force cygwin to use it's own package. In my user path variable resides only cygwin's bin folder, git-bash is in the system's path variable. How do I force the user path one to take precedence over the git-bash version? Shouldn't that be the dafault behaviour?
https://askubuntu.com/questions/58814/how-do-i-add-environment-variables
Seems to do the trick, I don't know if that is the optimal solution but it works. I just plugged this into my bashrc.
export PATH="C:\cygwin64\bin"
When installing git-flow I realized it is just putting files in /usr/local/bin mainly git-flow which is the executable, I'm able to invoke the script git-flow by running git flow (without dash in between). I then realized it is the same with git-svn as well where the commands are run with git svn.
Am I overlooking something basic or does git itself actually delegate the commands somehow?
The git binary remembers the directory where dashed executables like git-svn are installed. It is set during git installation, or to be more exact during build phase (that is why you need to use the same options compiling and installing).
You can find this directory with git --exec-path
$ git --exec-path
/usr/libexec/git-core
(the above is for system installation on Linux).
The git svn command (not a built in) invokes git wrapper, which finds git-svn binary, and executes it.
Note: some of dashed executables, corresponding to built-in commands, like git-tag, are hardlinked to git executable. Calling those just invokes appropriate (sub)command.
I have a version of SVN on my system in /usr/bin/svn. This is too old to use with some repositories so I compiled a newer version in /home/user/built/bin/svn which works fine. I added this to my PATH so it should be run first.
Typing
which svn
produces
/home/user/built/bin/svn
however typing
svn --version
reveals that it us using the old version still. if I run
/home/user/built/bin/svn --version
then the correct version is displayed.
Since the custom version is first in my $PATH, and which lists it first why is the older version being invoked when I run svn? I thought which used your $PATH to find executables in the same fashion as the shell?
Use
type svn
to figure out (a) what it is, (b) where it is or what its definition is. Also check that PATH really contains what you think it does
echo $PATH
Type gives:
type svn
svn is hashed (/usr/bin/svn)
Running
hash -r
has now fixed the problem!
Credit to the OP
You sure you don't have a symbolic link to svn somewhere else in your path?