Closed GoogleCodeExporter closed 8 years ago
Had the same issue today..
Original comment by dean...@thegreathardwarestore.com
on 27 Feb 2009 at 12:13
Same problem here, 1.6.1.3 installer on OSX 10.5.6 with custom .bash_profile
that includes the previous $PATH
setting.
Original comment by coderp...@gmail.com
on 14 Mar 2009 at 6:00
Same issue. Contents of my .profile:
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
Original comment by breckinl...@gmail.com
on 27 Mar 2009 at 11:24
I thought the installer uses /etc/paths.d, not $PATH. So I would not expect it
to change $PATH. Is the problem
that git is not on the path (in the abstract sense of path, i.e. things
executable by unqualified names) or just that
you want it to literally be part of the $PATH environment variable?
Original comment by Ben.Denc...@gmail.com
on 8 Apr 2009 at 4:14
Turns out the problem was not that the installer set /etc/paths.d incorrectly,
but that my OS X installation wasn't
set to use it by default. You need to have the lines:
if [ -x /usr/libexec/path_helper ]; then
eval `/usr/libexec/path_helper -s`
fi
in /etc/profile for this method of setting the system path to work. I would
check this during installation.
Original comment by ago...@gmail.com
on 11 Apr 2009 at 8:51
Thanks agocke, this was my problem as well.
Original comment by robertla...@gmail.com
on 9 Jul 2009 at 4:30
The problem is in the installation pakage.
The installer puts some folders on the wrong path.
man1, man5 and man7 was installed in the path: /usr/local/git/man rather that
/usr/local/git/share/man
Move these folders and everything will work fine.
Original comment by Saxint...@gmail.com
on 4 Sep 2009 at 9:47
Thanks Saxintosh....wasted 3 hours today.
Original comment by bazil...@gmail.com
on 8 Sep 2009 at 2:32
;-)
Original comment by Saxint...@gmail.com
on 8 Sep 2009 at 6:14
Original comment by timchar...@gmail.com
on 17 Sep 2009 at 7:27
Original issue reported on code.google.com by
ago...@gmail.com
on 29 Jan 2009 at 7:45