On Mon, 04 Feb 2013 07:42:26 +0000
Philip Oakley <philipoak...@iee.org> wrote:
[...]
> Hi, yes, I was really wanting to hack on the latest version. I've
> done a bit on the Msysgit version before, but to get at the Git core
> code it looks like working on Linux would be the best approach. So
> I'm trying to jump across the Windows -> Linux chasm now that I've go
> a second hand laptop (my son needed a new one for completing his
> engineering degree, so I repaired it and installed Ubuntu).
>
> At the moment I'd got the compile OK, the path OK, with 'which -a
> git' reporting the two versions (1.7.9.5 and 1.8.1.2.459), but 'git
> --version' reported the older one.
>
> I just rechecked this morning and see that the shutdown/reboot has
> sorted out the execution priority, but I'm not sure why !
I think of two reasons for this:
1) You did mess with the PATH environment variable in your ~/.profile
or ~/.bashrc or something like this, putting the "bin" directory of
your Git installation there. When you log in to the system, the
first process to be run with your credentials in your login shell
which reads its startup files and sets the environment inherited
by all the child processes (unless explicitly overridden for some
of them). So mere tweaking of your shell startup files affects
only the new shells you spawn (if you tweaked ~/.${shell}rc)
or the shell being run when logging in (if you tweaked ~/.profile).
2) Shells typically cache locations of programs which they look up in
the directories specified in the PATH environment variable. This
presents a considerable speed boost, but this comes at a price: if a
program which has been looked up (and cached) already changes its
location or is ablout to be "shadowed" by another instance (your
case, I reckon), the shell remains unaware about this.
To "fix" this, you usually has to run `hash -r` [1] in your shell
which makes it purge the cache, and so the next attempt to run a
program will find it in its new place.
In other words, next time you face an issue like this, first try to
purge the program lookup cache in your shell and see if this helps.
If it doesn't, try running another shell (possibly with the "-l" (ell)
command-line option to make it behave as a login shell) and see if this
helps. If it does, then logging out and in again will fix the
environment for the session. Rebooting is only needed in rare cases
like a security update of the kernel package.
1. http://pubs.opengroup.org/onlinepubs/009695399/utilities/hash.html
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
