{"thread":{"id":"27343","subject":"merging bare repository","startedAt":"2011-05-13T10:51:32Z","lastAt":"2011-06-06T21:54:33Z","messageCount":6,"participants":["Ilya Basin","Jeff King","Magnus Bäck","garyc618","Enrico Weigelt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"167790","messageId":"533718318.20110513145132@gmail.com","threadId":"27343","inReplyTo":null,"subject":"merging bare repository","fromName":"Ilya Basin","fromEmail":"basinilya@gmail.com","sentAt":"2011-05-13T10:51:32Z","receivedAt":"2011-05-13T10:51:32Z","isPatch":false,"sender":{"key":"basinilya@gmail.com","avatar":null},"body":"Hi list. Please suggest me a solution. There's a remote repository;\nwe're not allowed to push to. We have several committers.\nSo I want to create a local mirrror. We will push our changes to it.\nOnce in a while I want to sync this repo with upstream.\n\nHere's what I do:\n\non server:\n [git@server]$ git clone --bare ssh://git@some.org/git/project.git /git/project.git\n\non workstation:\n [me@client]$ git clone ssh://git@server/git/project.git\n [me@client]$ cd project\n [me@client]$ touch aaa\n [me@client]$ git add aaa\n [me@client]$ git commit aaa -m abracadabra\n [me@client]$ git push\n\nback on server:\n [git@server]$ git log\n commit e5c871122cadfa4ed4d2ab488852ecdb803b4bd8\n Author: Ilya Basin <>\n Date: Fri May 13 13:39:39 2011 +0400\n\n abracadabra\n\nI want to merge with upstream\n [git@server]$ git fetch\n [git@server]$ git merge origin\n fatal: This operation must be run in a work tree\n\nI read this article:\nhttp://www.pragmatic-source.com/en/opensource/tips/automatic-synchronization-2-git-repositories\nThe solution described there doesn't work\n\nIf I use --mirror instead of --bare to clone the repo, all local\ncommits discarded when I fetch.\n"},{"id":"167803","messageId":"20110513135348.GB10857@jpl.local","threadId":"27343","inReplyTo":"533718318.20110513145132@gmail.com","subject":"Re: merging bare repository","fromName":"Magnus Bäck","fromEmail":"magnus.back@sonyericsson.com","sentAt":"2011-05-13T13:53:48Z","receivedAt":"2011-05-13T13:53:48Z","isPatch":false,"sender":{"key":"magnus.back@sonyericsson.com","avatar":null},"body":"On Friday, May 13, 2011 at 12:51 CEST,\n Ilya Basin wrote:\n\n> Hi list. Please suggest me a solution. There's a remote repository;\n> we're not allowed to push to. We have several committers.\n> So I want to create a local mirrror. We will push our changes to it.\n> Once in a while I want to sync this repo with upstream.\n\nOkay, so you're forking an upstream git and periodically merging from\nit. Pretty standard behavior.\n\n> Here's what I do:\n> \n> on server:\n> [git@server]$ git clone --bare ssh://git@some.org/git/project.git /git/project.git\n> \n> on workstation:\n> [me@client]$ git clone ssh://git@server/git/project.git\n> [me@client]$ cd project\n> [me@client]$ touch aaa\n> [me@client]$ git add aaa\n> [me@client]$ git commit aaa -m abracadabra\n> [me@client]$ git push\n> \n> back on server:\n> [git@server]$ git log\n> commit e5c871122cadfa4ed4d2ab488852ecdb803b4bd8\n> Author: Ilya Basin <>\n> Date: Fri May 13 13:39:39 2011 +0400\n> \n> abracadabra\n> \n> I want to merge with upstream\n> [git@server]$ git fetch\n> [git@server]$ git merge origin\n> fatal: This operation must be run in a work tree\n\nDon't do the merge in the server-side bare git, do it somewhere you've\nmade a non-bare clone that has a worktree. A workstation would be the\nbest choice, but you could make such a clone on the server too (but I'd\navoid introducing a process in an organization that required people to\nbe able to logon to the Git server). Once you've actually done the merge\nyou can push the merge commit to the master branch of\nssh://git@server/git/project.git.\n\nTo deal with upstreams like this I recommend you place the upstream\nbranch(es) in a separate namespace prefixed by /, e.g.\ngithub/master if your upstream is the master branch from the official\nGithub repo of the project. Example:\n\n git fetch ssh://git@some.org/git/project.git\n git push ssh://git@server/git/project.git FETCH_HEAD:github/master\n\nIf you mirror the upstream branches like this on your server merges\nfrom upstream becomes trivial[*],\n\n git merge origin/github/master\n git push ssh://git@server/git/project.git HEAD:master\n\nand can be done on any workstation plus it's easy for your users to\ne.g. see what they've been up to compared to the upstream:\n\n git log origin/github/master..origin/master\n\nYou could update github/master as often as you wish, perhaps more often\nthan you do the actual merge to your own branch. That way your users can\neasily keep track of what goodies await them in the next merge from\nupstream.\n\n[*] I'm being unnecessarily explicit in the push operation just to\n show what's going on -- a plain \"git push origin\" will probably\n do the same thing.\n\n[...]\n\n-- \nMagnus Bäck Opinions are my own and do not necessarily\nSW Configuration Manager represent the ones of my employer, etc.\nSony Ericsson\n"},{"id":"167802","messageId":"20110513135412.GA6920@sigill.intra.peff.net","threadId":"27343","inReplyTo":"533718318.20110513145132@gmail.com","subject":"Re: merging bare repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-13T13:54:12Z","receivedAt":"2011-05-13T13:54:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 13, 2011 at 02:51:32PM +0400, Ilya Basin wrote:\n\n> on server:\n> [git@server]$ git clone --bare ssh://git@some.org/git/project.git /git/project.git\n> \n> on workstation:\n> [me@client]$ git clone ssh://git@server/git/project.git\n> [me@client]$ cd project\n> [me@client]$ touch aaa\n> [me@client]$ git add aaa\n> [me@client]$ git commit aaa -m abracadabra\n> [me@client]$ git push\n> \n> back on server:\n> [git@server]$ git log\n> commit e5c871122cadfa4ed4d2ab488852ecdb803b4bd8\n> Author: Ilya Basin <>\n> Date: Fri May 13 13:39:39 2011 +0400\n> \n> abracadabra\n> \n> I want to merge with upstream\n> [git@server]$ git fetch\n> [git@server]$ git merge origin\n> fatal: This operation must be run in a work tree\n\nYeah, you need a work tree to do a merge, as there may be conflicts.\nMoreover, you can't just do the merge via something like cron, as you\nmay need user intervention to resolve the conflicts.\n\nSo from your workstation, you'll want to do:\n\n git remote add upstream ssh://git@some.org/git/project.git\n git pull upstream\n\nwhenever you feel like merging with upstream.\n\n-Peff\n"},{"id":"171909","messageId":"20110513205646.GD24644@nibiru.local","threadId":"27343","inReplyTo":"20110513135348.GB10857@jpl.local","subject":"Re: merging bare repository","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2011-05-13T20:56:47Z","receivedAt":"2011-05-13T20:56:47Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Magnus Bäck wrote:\n\n\n\nBTW: if you're ontop of some external upstream, you might like\nto rebase instead of merge.\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"169037","messageId":"1306807292356-6421097.post@n2.nabble.com","threadId":"27343","inReplyTo":"20110513135348.GB10857@jpl.local","subject":"Re: merging bare repository","fromName":"garyc618","fromEmail":"gary.carter@eigen.com","sentAt":"2011-05-31T02:01:32Z","receivedAt":"2011-05-31T02:01:32Z","isPatch":false,"sender":{"key":"gary.carter@eigen.com","avatar":null},"body":"\nMagnus Bäck-2 wrote:\n> \n> \n> Don't do the merge in the server-side bare git, do it somewhere you've\n> made a non-bare clone that has a worktree. A workstation would be the\n> best choice, but you could make such a clone on the server too (but I'd\n> avoid introducing a process in an organization that required people to\n> be able to logon to the Git server). Once you've actually done the merge\n> you can push the merge commit to the master branch of\n> ssh://git@server/git/project.git.\n> \n> To deal with upstreams like this I recommend you place the upstream\n> branch(es) in a separate namespace prefixed by /, e.g.\n> github/master if your upstream is the master branch from the official\n> Github repo of the project. Example:\n> \n> git fetch ssh://git@some.org/git/project.git\n> git push ssh://git@server/git/project.git FETCH_HEAD:github/master\n> \n> If you mirror the upstream branches like this on your server merges\n> from upstream becomes trivial[*],\n> \n> git merge origin/github/master\n> git push ssh://git@server/git/project.git HEAD:master\n> \n> and can be done on any workstation plus it's easy for your users to\n> e.g. see what they've been up to compared to the upstream:\n> \n> git log origin/github/master..origin/master\n> [...]\n> \n\nCould you explain more about how this works - where do I find the character\nstring to use instead of \"github\". It can't be arbitrary, I got an error\nmessage.\nWhen I did the fetch it said\n*branch HEAD -> FETCH_HEAD\ncould you explain what this means in more detail?\n\nWe enthusiasts-who-don't-have-time-to-become-git-masters really need some\nwell explained examples if we're going to be able to convince management\nthat git is not some super complicated tool that takes weeks to learn. The\nparticular use case described in this thread is the last sticking point I\nhave to make work before I can show git doing everything we need it to do to\nmy management.\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/merging-bare-repository-tp6358945p6421097.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"169414","messageId":"20110606215433.GC29348@jpl.local","threadId":"27343","inReplyTo":"1306807292356-6421097.post@n2.nabble.com","subject":"Re: merging bare repository","fromName":"Magnus Bäck","fromEmail":"magnus.back@sonyericsson.com","sentAt":"2011-06-06T21:54:33Z","receivedAt":"2011-06-06T21:54:33Z","isPatch":false,"sender":{"key":"magnus.back@sonyericsson.com","avatar":null},"body":"On Tuesday, May 31, 2011 at 04:01 CEST,\n garyc618 wrote:\n\n> Magnus Bäck-2 wrote:\n\n[...]\n\n> > To deal with upstreams like this I recommend you place the upstream\n> > branch(es) in a separate namespace prefixed by /, e.g.\n> > github/master if your upstream is the master branch from the\n> > official Github repo of the project. Example:\n> > \n> > git fetch ssh://git@some.org/git/project.git\n> > git push ssh://git@server/git/project.git FETCH_HEAD:github/master\n> > \n> > If you mirror the upstream branches like this on your server merges\n> > from upstream becomes trivial[*],\n> > \n> > git merge origin/github/master\n> > git push ssh://git@server/git/project.git HEAD:master\n> > \n> > and can be done on any workstation plus it's easy for your users to\n> > e.g. see what they've been up to compared to the upstream:\n> > \n> > git log origin/github/master..origin/master\n> > [...]\n> > \n> \n> Could you explain more about how this works - where do I find the\n> character string to use instead of \"github\". It can't be arbitrary,\n> I got an error message.\n\nCan you be more specific about the error message? The string *is*\narbitrary. The only thing I can think of is that you need to specify\nrefs/heads/github/master rather than just github/master in the push\noperation.\n\n> When I did the fetch it said\n> *branch HEAD -> FETCH_HEAD\n> could you explain what this means in more detail?\n\nSomeone might need to correct my here, but I guess it means that the\nlocal symbolic ref FETCH_HEAD has been updated with the contents of\nthe server-side symbolic ref HEAD. The important part to remember\nhere is that FETCH_HEAD is a useful shorthand that represent what you\ngot in the last fetch operation.\n\nCome to think of it, the first example commands that you're commenting\nmight not necessarily do what you want. It's probably a good idea to\nspecify the ref explicitly instead of FETCH_HEAD, e.g. origin/master,\nor just fetch the branch you want. I don't know what FETCH_HEAD contains\nwhen multiple refs are fetched.\n\n> We enthusiasts-who-don't-have-time-to-become-git-masters really need\n> some well explained examples if we're going to be able to convince\n> management that git is not some super complicated tool that takes\n> weeks to learn.\n\nIf you're the one who's going to be managing your source code\nrepositories, any tool for this task will take weeks if not months to\nmaster sufficiently well. Learning how to use a source control system\nlike Git isn't just about learning the tool itself -- that part is\nusually easy. Regardless of the choice of tool, you'll have to learn its\nins and outs and how to apply it to your probably already established\nprocesses, and/or how you should change your processes to adapt to the\ntool (you probably need a little bit of both).\n\nAny manager claiming that doing this properly is trivial with any tool\nshouldn't be making decisions about this. Really.\n\n> The particular use case described in this thread is the last sticking\n> point I have to make work before I can show git doing everything we\n> need it to do to my management.\n\nLuckily integrating upstream development with your own is easy with Git\nand probably all other distributed version control systems. I think it's\none of their major strengths.\n\n-- \nMagnus Bäck Opinions are my own and do not necessarily\nSW Configuration Manager represent the ones of my employer, etc.\nSony Ericsson\n"}]}