Newbie experience with push over ssh

Hi,

I'm playing a bit with git (still ~ total beginner).

I could create a local repository, commit in it, but then, I tried to push it to a remote machine, on which git is installed.

I would have expected "push" to do this, but:

$ git push ssh://machine.fr/tmp/foo fatal: '/tmp/foo': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly

Then, I tried "clone":

$ git clone . ssh://machine.fr/tmp/foo
Initialized empty Git repository in /tmp/foo/ssh:/machine.fr/tmp/foo/.git/
remote: Generating pack...
remote: Done counting 3 objects.
remote: Deltifying 3 objects.
 100% (3/3) done/3) done
remote: Total 3 (delta 0), reused 0 (delta 0)
Indexing 3 objects.
 100% (3/3) done

Gosh, "push" seems to know what a URL is, but not "clone", which considers the _file_ ssh:/machine.fr/tmp/foo ...

Then only, I understood that I would have to log onto the remote machine, and mkdir + git init manually. At least, this should be mentionned in the git-push man page, but indeed, is there any reason why git-push could not just create the remote repository? And any reason why clone doesn't deal with URLs?

Thanks,

Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

git push is can only push into an existing repository, there seems to be no repository in /tmp/foo on machine.fr.

This means: "clone the repository at . to the directory ssh://machine.fr/tmp/foo". The first parameter is the repository to clone from, the second is the directory to put the clone into (this is optional).

I don't think there is any way to 'clone to remote'. You'd have to ssh to the other machine and clone from there, or you can just create an empty repository on the remote host and push the stuff into it.

Matthias Lederhofer wrote:

I remember coming across the same issue as Matthieu and never got round to solving it. In my case the desire is to upload the code onto a remote machine---in particular a cluster where I run simulations. I don't particularly need that remote code to be in a repo or otherwise, since it's only there to be run, not edited.

As far as I know I have no way of installing git on that machine. Perhaps I could install it locally but I suspect the sysadmin would not be supportive.

So, is there a way of using git to upload my code to a machine without a repo ready-prepared?

On Wednesday, February 14, 2007 at 16:10:45 (+0000) Joseph Wakeling writes:

If you must ...

% cat ~/.gitconfig
[alias]
	scp !scp
	rcp !rcp
% git scp -rp . me@remotehost:/directory

Bill

Bill Lear wrote:

Thanks very much. And (should have asked this first ....) is it possible to init a repo remotely, i.e. to use the git on my machine to do init-repo on a directory accessed via ssh or ftp? And if yes ... to do other git commands similarly remotely?

The latter would be a slow and painful way of working, I imagine, but might be useful.

On Wednesday, February 14, 2007 at 10:25:05 (-0600) Bill Lear writes:

Actually that was a bit tongue-in-cheek, syntactically incorrect (I believe missing '='), I'm not actually sure it will work, nor if the patch for this actually got in to 1.5.0. The patch I saw does not appear to pass the rest of the command line to the system call, but perhaps I'm wrong and someone else can confirm.

If the patch to do this is reasonable, I would expect the command:

% git scp -rp . me@remotehost:/directory

to expand to:

% scp -rp . me@remotehost:/directory

and if not, I think it should, just as when I have:

[alias]
	pub = push /my/repo

and:

% git pub branch:branch

expands to:

% git push /my/repo branch:branch

Bill

Bill Lear wrote:

Can you explain in detail exactly what your .gitconfig modifications are doing? If I understand right, is there any particular point in bothering with these aliases, is it not just equivalent to using scp by itself?

On Wednesday, February 14, 2007 at 16:48:19 (+0000) Joseph Wakeling writes:

Well, that was my tongue-in-cheek bit. My intent was to just say "Why not simply use scp/rcp/rsync, whatever?", as that seemed to be what you were asking git to do. But, if you had to do it, I thought you could, using the aliases I outlined (and, as it turns out, I may have even been wrong about that).

Bill

Joseph Wakeling <joseph.wakeling@webdrake.net> writes:

Not any. The joke was just "if you insist in having git at the beginning of the command line, ...".

Matthieu Moy wrote:

Forgive me, I have a BAAD cold today and many things are going over my head .... :-)

That is frustrating, though, that I can't push/upload code in the same way as I can with bzr. Unless I _can_ init-repo on the remote machine with the git on my own .... ?

On Wed, 14 Feb 2007, Joseph Wakeling wrote:

What would be the point if you don't have GIT on the remote system?

Just use rsync or scp to copy your code over and be happy.

Nicolas

Nicolas Pitre wrote:

For one thing, I might be making small changes or have unversioned files in my local directory that I don't want to copy. I only want to push across the latest code in the branch.

On Wed, Feb 14, 2007 at 05:47:03PM +0000, Joseph Wakeling wrote:

rsync will efficiently push small changes. Just feed it input from git's list of versioned files:

git ls-files -z | rsync -a --files-from=- -0 . host:/path/to/dest

-Peff

On Wed, 14 Feb 2007, Joseph Wakeling wrote:

Try this then:

  git archive --format=tar <branch_name> | ssh <remote_machine> tar -xf -

You can also use the --prefix= argument to git-archive in order to specify a subdirectory on the remote machine.

Nicolas

Bill Lear <rael@zopyra.com> writes:

[ in this case, I'd prefer using rsync ]

Well, this does not the same as being able to really use git to push. First, you have no guarantee that the repository will be consistent during the push. I belive the git repository format is relatively safe with this regard since git doesn't rewrite data in-place, so the worst that can happen is probably that someone gets a reference to a not-yet-uploaded object.

But the real advantage of using the version control system to upload is to avoid the case of

$ cd /path/to/dumb/project $ rsync ./ path:to/very/important/project/

since rsync/scp are not designed to look at the content of the destination before overriding it. Using git, I believe such miss-manipulation could lead to having irrelevant data in a repository, but not to data-loss.

Bill Lear wrote:

:-)

Perhaps a better solution would be to do

git archive --format=tar --prefix=project/ | bzip2 -f9 | \
	ssh user@remote -C "cat > project.tar.bz2"

Then unpack and build as usual on the remote end. Works a treat and is currently the gist of the only line in my "push-to-web" script (the rest of it just extends the command to run to also unpack the tarball).

Joseph Wakeling <joseph.wakeling@webdrake.net> wrote:

git archive --format=tar HEAD | ssh remote 'cd /some/where;tar xvf -'

You could put this in a shell script which takes the remote hostname, path and optionally the revision to send..

Matthias Lederhofer wrote:

Aaahhh, that looks quite an elegant solution.  Thank you very much!