merging bare repository

merging bare repository

[Ilya Basin]

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://git@some.org/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.

Re: merging bare repository

[Magnus Bäck]

On Friday, May 13, 2011 at 12:51 CEST,
     Ilya Basin <basinilya@gmail.com> wrote:

> 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.

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

> Here's what I do:
> 
> on server:
>     [git@server]$ git clone --bare ssh://git@some.org/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

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://git@some.org/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

Re: merging bare repository

[Jeff King]

On Fri, May 13, 2011 at 02:51:32PM +0400, Ilya Basin wrote:

> on server:
>     [git@server]$ git clone --bare ssh://git@some.org/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

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://git@some.org/git/project.git
  git pull upstream

whenever you feel like merging with upstream.

-Peff

Re: merging bare repository

[Enrico Weigelt]

* Magnus Bäck <magnus.back@sonyericsson.com> 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: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: merging bare repository

[garyc618]

Magnus Bäck-2 wrote:
> 
> 
> 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://git@some.org/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
> [...]
> 

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.

Re: merging bare repository

[Magnus Bäck]

On Tuesday, May 31, 2011 at 04:01 CEST,
     garyc618 <gary.carter@eigen.com> wrote:

> Magnus Bäck-2 wrote:

[...]

> > 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://git@some.org/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
> > [...]
> > 
> 
> 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.

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.

> When I did the fetch it said
> *branch HEAD -> FETCH_HEAD
> could you explain what this means in more detail?

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.

> 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.

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.

> 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.

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