merging bare repository

Hi list. Please suggest me a solution. There's a remote repository; we're not allowed to push to. We have several committers. So I want to create a local mirrror. We will push our changes to it. Once in a while I want to sync this repo with upstream.

Here's what I do:

on server:

    [git@server]$ git clone --bare ssh://[email protected]/git/project.git /git/project.git

on workstation:

    [me@client]$ git clone ssh://git@server/git/project.git
    [me@client]$ cd project
    [me@client]$ touch aaa
    [me@client]$ git add aaa
    [me@client]$ git commit aaa -m abracadabra
    [me@client]$ git push

back on server:

    [git@server]$ git log
    commit e5c871122cadfa4ed4d2ab488852ecdb803b4bd8
    Author: Ilya Basin <>
    Date:   Fri May 13 13:39:39 2011 +0400

abracadabra

I want to merge with upstream

    [git@server]$ git fetch
    [git@server]$ git merge origin
    fatal: This operation must be run in a work tree

I read this article:
http://www.pragmatic-source.com/en/opensource/tips/automatic-synchronization-2-git-repositories
The solution described there doesn't work

If I use --mirror instead of --bare to clone the repo, all local commits discarded when I fetch.

Okay, so you're forking an upstream git and periodically merging from it. Pretty standard behavior.

Don't do the merge in the server-side bare git, do it somewhere you've made a non-bare clone that has a worktree. A workstation would be the best choice, but you could make such a clone on the server too (but I'd avoid introducing a process in an organization that required people to be able to logon to the Git server). Once you've actually done the merge you can push the merge commit to the master branch of ssh://git@server/git/project.git.

To deal with upstreams like this I recommend you place the upstream branch(es) in a separate namespace prefixed by <upstreamname>/, e.g. github/master if your upstream is the master branch from the official Github repo of the project. Example:

git fetch ssh://[email protected]/git/project.git
git push ssh://git@server/git/project.git FETCH_HEAD:github/master

If you mirror the upstream branches like this on your server merges from upstream becomes trivial[*],

git merge origin/github/master
git push ssh://git@server/git/project.git HEAD:master

and can be done on any workstation plus it's easy for your users to e.g. see what they've been up to compared to the upstream:

git log origin/github/master..origin/master

You could update github/master as often as you wish, perhaps more often than you do the actual merge to your own branch. That way your users can easily keep track of what goodies await them in the next merge from upstream.

[*] I'm being unnecessarily explicit in the push operation just to
show what's going on -- a plain "git push origin" will probably do the same thing.

[...]

Magnus Bäck                   Opinions are my own and do not necessarily
SW Configuration Manager      represent the ones of my employer, etc.
Sony Ericsson

Could you explain more about how this works - where do I find the character string to use instead of "github". It can't be arbitrary, I got an error message.
When I did the fetch it said
*branch HEAD -> FETCH_HEAD
could you explain what this means in more detail?

We enthusiasts-who-don't-have-time-to-become-git-masters really need some well explained examples if we're going to be able to convince management that git is not some super complicated tool that takes weeks to learn. The particular use case described in this thread is the last sticking point I have to make work before I can show git doing everything we need it to do to my management.

--
View this message in context: http://git.661346.n2.nabble.com/merging-bare-repository-tp6358945p6421097.html
Sent from the git mailing list archive at Nabble.com.

[...]

Can you be more specific about the error message? The string *is* arbitrary. The only thing I can think of is that you need to specify refs/heads/github/master rather than just github/master in the push operation.

Someone might need to correct my here, but I guess it means that the local symbolic ref FETCH_HEAD has been updated with the contents of the server-side symbolic ref HEAD. The important part to remember here is that FETCH_HEAD is a useful shorthand that represent what you got in the last fetch operation.

Come to think of it, the first example commands that you're commenting might not necessarily do what you want. It's probably a good idea to specify the ref explicitly instead of FETCH_HEAD, e.g. origin/master, or just fetch the branch you want. I don't know what FETCH_HEAD contains when multiple refs are fetched.

If you're the one who's going to be managing your source code repositories, any tool for this task will take weeks if not months to master sufficiently well. Learning how to use a source control system like Git isn't just about learning the tool itself -- that part is usually easy. Regardless of the choice of tool, you'll have to learn its ins and outs and how to apply it to your probably already established processes, and/or how you should change your processes to adapt to the tool (you probably need a little bit of both).

Any manager claiming that doing this properly is trivial with any tool shouldn't be making decisions about this. Really.

Luckily integrating upstream development with your own is easy with Git and probably all other distributed version control systems. I think it's one of their major strengths.

Magnus Bäck                   Opinions are my own and do not necessarily
SW Configuration Manager      represent the ones of my employer, etc.
Sony Ericsson

* Magnus Bäck <[email protected]> wrote:

<snip>

BTW: if you're ontop of some external upstream, you might like to rebase instead of merge.

cu

----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: [email protected]
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Yeah, you need a work tree to do a merge, as there may be conflicts. Moreover, you can't just do the merge via something like cron, as you may need user intervention to resolve the conflicts.

So from your workstation, you'll want to do:

git remote add upstream ssh://[email protected]/git/project.git git pull upstream

whenever you feel like merging with upstream.

-Peff