The Dev Pages

A knowledge base for simple (and beyond) web applications development

Archive for the ‘git’ Category




So if you need to explicitly set the upload-pack path on a git command using the msysgit shell, you’ll get a weird error. Apparently msys mucks up (in a lot of cases this is actually the desired behavior) paths. MSys alters the unix style path you entered to be windows style and prepends it with C:\PATHTOYOURGIT. This obviously confuses the server and causes a msysgit error on upload pack.

bash: C:/Git/PATHTOYOURUPLOADPACK/git-upload-pack: No such file or directory
fatal: The remote end hung up unexpectedly

So to fix this (which was a pain in the ass to find!) you simply begin path arguments with an extra slash.

git clone –upload-pack /home/myuser/bin/git-upload-pack myuser@mydomain.com:/home/myuser/gitprojects/agitproject.git

becomes

git clone –upload-pack //home/myuser/bin/git-upload-pack myuser@mydomain.com:/home/myuser/gitprojects/agitproject.git

http://osdir.com/ml/msysgit/2010-03/msg00139.html

- If you want to specify a different location for –upload-pack, you have
to start the absolute path with two slashes. Otherwise MSys will mangle
the path. git and bash have serious problems with non-ASCII file names
(Issue 80, 159).




I had done a git rm of some swp files (I had forgotten to put *.swp in my .gitignore for this project) and after committing, I pushed to the remote origin and was suprised to see:

error: unable to create temporary sha1 filename ./objects/19: File exists

If you get this error (Where 19 is a number unique to your situation), then it is probably a permissions issue. On the remote server, make sure the remote bare repos, and ALL subfolders and files are owned by the appropriate (usually git) user. What is annoying is that somehow in the course of pretty normal git tasks, a non-git user was assigned ownership, or the git user was denied rights somehow. I forgot to check what the bad permissions were before I chowned and chgrped the files.

Once I logged in as an admin, changed to the git user’s home directory where all the remote bare repos exist, and issued ’sudo chown -R git ./’ and ’sudo chgrp -R git ./’ all was well.

I think the way to avoid this error is to make sure you are using the git user if you are pushing changes on the same server as the remote git repos.

See a more in depth discussion at http://kerneltrap.org/mailarchive/git/2008/11/28/4258264/thread




When doing a push to master I was getting

bash: git-upload-pack: command not found
bash: git-receive-pack: command not found

The skinny: The path on your remote machine is not correct, at least the path being used for non-interactive shell logins. Most likely, updating the .bashrc of the remote user, (the user in the command) will fix your problem. Note that nothing on the client side of things really matters except that you have git-core installed and you may save a path to git-upload-pack in your local git settings if you wanted to.

Hoo boy, I have updated this after a not-so-fun experience with bluehost, ssh, bash, and git. After getting my ass kicked for two hours, turns out that my hosting issued some ssh updates that made it so no .bashrc or .bash_profile settings were being used for setting the path on shell logins and commands. Very nice.

Fix your path

Key 1: Figure out where the binaries for git are on the remote system. On my lame-o shared server they were in /home/<myusername>/local/bin. The folder will have a bunch of programs, or at least git, gitk, git-shell, git-upload-pack, etc.
Key 2: Make sure the path for your non-interactive shell login contains the folder where your git binaries are located. This following command, from the stackoverflow post, is awesome for seeing the ‘non-interactive shell’ path. Matt Curtis is great.

ssh you@remotemachine echo \$PATH

So if the result of ssh you@remotemachine echo \$PATH does not contain the folder where your git binaries are located, this is the source of the problem.

On the remote machine, login to the user being used for the git command, and make sure the .bashrc file sets the path correctly. You may not even need to add anything, but if you are reading this post chances are you need to include

export PATH=$PATH:/<pathtoyourgitbinaries>

in your .bashrc.

For all of us who didn’t immediately grasp what a ‘non-interactive shell login’ is, it goes as follows. When you login to a linux machine over ssh or at a desktop, this is an ‘interactive’ shell session, and loads the settings for the shell from .bash_profile in the home folder of the user who us logged in.

If you are simply issuing commands without logging in (like git clone, ssh somecommand, etc., or I guess just opening a bunch of shells in an os) then you are using a ‘non-interactive’ shell session. This will load settings from the .bashrc in the home folder of the user who us logged in.

A lot of times systems will have the .bash_profile call the .bashrc, so most relevant settings can go in the .bashrc.

But the difference in interactivity is why logging into an ssh session and doing echo $PATH will display a different path then issuing a non-interactive command like ssh you@remotemachine echo \$PATH.

Alternately, explicitly state the path to the git-upload-pack binary

If you can’t get the path settings in your (remote) .bashrc to work, you can tell git exactly where to look for the git-upload-pack binary. So bluehost users, or anyone else who has no control over the path setting for shells, you can explicitly use the –upload-pack option to explicitly set the path to the git-upload-pack binary you want. Example (Note that the upload-pack is an option with 2 hyphens -andanother- ):

git clone –upload-pack /home/<username>/bin/git-upload-pack <username>@<yourdomain>:/home/<username>/gitprojects/agitproject.git

If you have a git user for bare remote repos it will probably look like:

git clone –upload-pack /<somepathtoyourgitbinaries>/git-upload-pack git@<yourdomain>:agitproject.git

You can also add the server paths to your local git config

receivepack = /home/<myusername>/local/bin/git-receive-pack
uploadpack = /home/<myusername>/local/bin/git-upload-pack

where the config file is in the .git directory of my project on local. This line is under the entry for the remote I had set up called ‘origin’ (use the path on the server where the git install is located and make sure git-receive-pack is in there on the server).

Bluehost users getting the git-upload-pack: command not found error, or similar command not found errors can see the explanation of why you can’t control your .bashrc at http://66.147.243.109/index.php/kb/article/000572

See http://stackoverflow.com/questions/225291/git-upload-pack-command-not-found-how-to-fix-this-correctly