Scott has several posts about git (1, 2, 3), and the “I worked on this locally, now I want to push this to a remote place where others will be able to fetch it”.
I’ve been using the following snippet for that. YMMV.
REPO=reponame
ROOT=/wheremygitreposare/
SERV=remoteserver
git clone --bare . /tmp/${REPO}.git && \
rsync -avzP /tmp/${REPO}.git ${SERV}:$ROOT && \
git remote add origin ${SERV}:${ROOT}${REPO}.git && \
git config branch.master.remote origin && \
git config branch.master.merge refs/heads/master
(Please post comments if you can improve it!)
But I totally agree that this common use case is not well addressed in git.
I prefer to go to the remote server, “GIT_DIR=/path/to/repo.git git init”, then locally “git remote add origin ssh://server/path/to/repo”, and “git push origin master:master”.
I do find it annoying to have to add the config snippets for merging master from origin, though.
Here’s what I do (going from memory, may be slightly off):
On my server:
mkdir /repos/foo.git
cd /repos/foo.git
git init –bare
On my development machine, in the working copy directory:
git push ssh://remote-machine/repos/foo.git name-of-branch
name-of-branch is usually “master”, at least for what I do. I guess my way isn’t that much less complicated (after doing the git add remote and git config branch* convenience stuff), but at least it doesn’t make a copy in /tmp. I can then, of course, update with git push.
Scott’s use case was just to publish branches in a shared repo, if I understood correctly. For that, all you need is:
$ git clone –bare ~/repo shared.git
$ touch shared.git/git-daemon-export-ok # if you want to export using git-daemon
# copy shared.git to your server using scp, rsync, or whatever
$ git push user@host:shared.git new:new
The User’s Manual covers this in Setting up a public repo and Pushing changes to a public repo.
Your example seems to also switch your local repo into being a clone of that shared repo, so you can fetch from it. Presumably because your use case is a central repo that others also push into? If so, you could just throw away your original repo and then clone the shared repo you just created instead of manually fixing up the config.
Of course, another option is for the collaborators to publish their own repos. Then you just add those as remotes directly. One benefit is that you don’t have to host a writable public repo.
Git lets you choose :)
Just copy the .git dir via SSH and that’s it! gosh! then create a empty local repo and add the remote, is that hard?
I think git_remote_branch is essential, and it (or equivalent) should be part of git. It makes much of the work of syncing remote and local branches as straightforward as it ought to be.
grb publish my-branch
Done. (The remote repo does have to exist though).
Has anyone at all thought about filing bugs upstream or posting some of this discussion upstream on the git mailinglist?
The 1.6.x branch of git was a major leap forward in the usability dept.
why not stick
set -e
at that start and then lose all the &&
@Tom: because I usually copy/paste that code snippet in a terminal.
I have a small function in my zshrc which basically does what you’ve written, but also some extra helpful steps:
http://git.jonnylamb.com/?p=dotfiles.git;a=blob;f=zshrc;hb=HEAD#l234