Git Confusion

Hi all,

I'm new to git and probably doing something very dumb, but I can't seem to resolve this.

I have a remote repository and a local one. I ssh to the remote machine, goto the repository directory (not a bare repository), edit a file and commit it. All if fine.

I leave the remote host and go into the local git directory. Doing "git pull origin master" says "Already up-to-date." but there is a file I changed remotely, and I want to pull it locally!

The local repo was made with "git clone http://example.com/.git". I have no branching (both are on master).

My way around this, is on the remote server, I do a "git push other master", and then on the local one I do "git checkout HEAD file1" for each file. Painful and I'm sure it is wrong.

Any ideas? How do you debug this?

Thanks Paul

On Fri, May 29, 2009 at 12:43:35AM -0700, Paul Tarjan wrote:

Your repository is accessed over http. You need to run "git update-server-info" to build the files for clients to see the actual updates.

Usually such a repo is bare, and gets updates only by push. In that case, enabling the update hook to run update-server-info is sufficient. But in your case, you are actually working on the remote repo via commit and other means, so there is no convenient way to always update-server-info after a change.

Is there a particular reason you cloned over http instead of over ssh?

-Peff

Jeff King <peff@peff.net> writes:

Well, he can always add git-update-server-info to post-commit hook.

Or git protocol?

On Fri, May 29, 2009 at 06:44:26AM -0700, Jakub Narebski wrote:

That covers committing, but what about reset, rebase, "branch -f", etc? I don't think there is a catch-all for all the ways that a repo can be updated locally.

Yes, that would work fine, too. I mentioned ssh because he already indicated that he was able to ssh into the box (and may or may not have the git daemon set up).

-Peff

Thank you very much. For skimmers the solution is :

git update-server-info

every time I do something to the remote repo.

The reason I need http is slightly convoluted. The remote machine is shared hosting with 1 ssh login that I don't want to give to my partner AND I don't have root on that box. And as you correctly guessed, that box doesn't have the git demon. The local machine where he is doing his development. The only solution I saw without giving him my username + pass to SSH was to do http cloning. Any better solutions?

Thanks guys, a great first intro to the git community.

Paul Tarjan

On Fri, May 29, 2009 at 6:52 AM, Jeff King <peff@peff.net> wrote:

On Fri, May 29, 2009 at 4:24 PM, Paul Tarjan <ptarjan@gmail.com> wrote:

It dosen't have the git daemon, or it's not running the git daemon? You can just run it yourself from your user account, and it's kind of weird that it wouldn't exist. (You could build it or copy the binary from another machine, I suppose.)

Have fun,

Avery

On Fri, May 29, 2009 at 01:24:59PM -0700, Paul Tarjan wrote:

You can let him login via ssh key and restrict the actions of that key just to running git-upload-pack (which is what "git clone" and "git fetch" will invoke to clone or fetch commits). Something like:

  command="git-upload-pack /path/to/repo" ssh-rsa ...

in your .ssh/authorized_keys file. Not that he still won't be able to actually push (which is maybe what you want).

For a more featureful solution (with permissions for pushing and pulling multiple repos), I think gitosis will do what you want (but I have never used it personally).

-Peff

On 2009-05-29 20:38:54, Jeff King <peff@peff.net> wrote:

[snip]

gitosis is indeed quite featureful. I use it at work to admin about 11 projects with between 1-6 devs and it works very well. All done with ssh pubkey and the "command=" feature of .ssh/authorized_keys that Jeff mentioned above, with a bit of python to read a conf file and decide who is allowed to read/write what repository etc.

On Fri, 29 May 2009, Paul Tarjan wrote:

I see two possible solutions (and you can use both):

1. Have separate publishing repository, which would be bare, and updated
   only via push (so enabling 'update' / 'post-receive' hooks would be
   enough for HTTP). This is good idea also because it makes it possible
   to change commits (rewrite history), e.g. do "git commit --amend"...
   provided that you didn't push part of history you are changing to
   public repository. If you are worrying about disk space, you can
   always set up alternates.

2. Use Gitosis (or ssh_acl) to control access via SSH to repository
   without need to provide extra user accounts, or use git-shell as
   login shell for user accounts which are meant only to access
   repositories. I think you can use Gitosis without being a root...
   see link in BlogPosts page at Git Wiki.

On 2009-05-29 20:45:55, Jakub Narebski <jnareb@gmail.com> wrote:

you don't need root for gitosis. However, this means you will be using your own "regular work" userid to host gitosis also, which is a wee bit fiddly.

Apart from things like fixing up PYTHONPATH in advance, adding a "--prefix=DIR" to the install command, etc., you should also remember that any pubkey added to gitosis becomes a "git only" user, so normal ssh won't work for him anymore. If your own access to the machine which is now your gitosis server is via pubkey, you may find yourself locked out -- don't add that pubkey to gitosis :-)

If the original poster needs more info, I will be happy to give more details.