{"thread":{"id":"32039","subject":"bare vs non-bare <1.7 then >=1.7 ?","startedAt":"2012-11-08T10:11:30Z","lastAt":"2012-11-10T10:29:33Z","messageCount":5,"participants":["Mihamina Rakotomandimby","Carlos Martin Nieto","Jeff King","Enrico Weigelt","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"202632","messageId":"509B8552.4080303@rktmb.org","threadId":"32039","inReplyTo":null,"subject":"bare vs non-bare <1.7 then >=1.7 ?","fromName":"Mihamina Rakotomandimby","fromEmail":"mihamina@rktmb.org","sentAt":"2012-11-08T10:11:30Z","receivedAt":"2012-11-08T10:11:30Z","isPatch":false,"sender":{"key":"mihamina@rktmb.org","avatar":"https://gravatar.com/avatar/b52e5d85625fd27eecfea3f3fa827a29140ac806bbdb29d0d79088a55e046a17?d=mp&s=160"},"body":"Hi all,\n\nWe're on the way to have our first project using Git.\nWe're currently mostly using Hg (90%) & SVN (10%).\n\nWhen experimenting in order to train some colleagues, I saw that If I \nclone a repository, I couldn't push to it because it was a non-bare one.\nSearchin for some explanations, I found this ressource:\nhttp://www.bitflop.com/document/111\n\nIt's told to be reliable information for Git < v1.7.\n\nWhat would be different for Git > 1.7 so that I could be up to date with \nthe facts?\n\nThank you.\n\n-- \nRMA.\n"},{"id":"202637","messageId":"87zk2sz0mn.fsf@flaca.cmartin.tk","threadId":"32039","inReplyTo":"509B8552.4080303@rktmb.org","subject":"Re: bare vs non-bare <1.7 then >=1.7 ?","fromName":"Carlos Martin Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-11-08T13:26:40Z","receivedAt":"2012-11-08T13:26:40Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"Mihamina Rakotomandimby writes:\n\n> Hi all,\n>\n> We're on the way to have our first project using Git.\n> We're currently mostly using Hg (90%) & SVN (10%).\n>\n> When experimenting in order to train some colleagues, I saw that If I\n> clone a repository, I couldn't push to it because it was a non-bare\n> one.\n> Searchin for some explanations, I found this ressource:\n> http://www.bitflop.com/document/111\n>\n> It's told to be reliable information for Git < v1.7.\n>\n> What would be different for Git > 1.7 so that I could be up to date\n> with the facts?\n\nBare vs. non-bare hasn't changed. The reasoning behind the two types\nhasn't changed and is pretty fundamental. There is no reason for it to\nchange.\n\n cmn\n"},{"id":"202643","messageId":"20121108145951.GA15560@sigill.intra.peff.net","threadId":"32039","inReplyTo":"87zk2sz0mn.fsf@flaca.cmartin.tk","subject":"Re: bare vs non-bare <1.7 then >=1.7 ?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-08T14:59:52Z","receivedAt":"2012-11-08T14:59:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 08, 2012 at 02:26:40PM +0100, Carlos Martín Nieto wrote:\n\n> > When experimenting in order to train some colleagues, I saw that If I\n> > clone a repository, I couldn't push to it because it was a non-bare\n> > one.\n> > Searchin for some explanations, I found this ressource:\n> > http://www.bitflop.com/document/111\n> >\n> > It's told to be reliable information for Git < v1.7.\n> >\n> > What would be different for Git > 1.7 so that I could be up to date\n> > with the facts?\n> \n> Bare vs. non-bare hasn't changed. The reasoning behind the two types\n> hasn't changed and is pretty fundamental. There is no reason for it to\n> change.\n\nRight. The key thing that changed in git v1.7 is that we started warning\nabout and denying an operation that had always been dangerous, and that\nis why the referenced document mentions that version.\n\n-Peff\n"},{"id":"202740","messageId":"e4dc73e8-69f9-4695-b8f7-cbc0f04e8197@zcs","threadId":"32039","inReplyTo":"509B8552.4080303@rktmb.org","subject":"Re: bare vs non-bare <1.7 then >=1.7 ?","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-11-10T08:23:07Z","receivedAt":"2012-11-10T08:23:07Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"\n> When experimenting in order to train some colleagues, I saw that If I\n> clone a repository, I couldn't push to it because it was a non-bare\n> one.\n> Searchin for some explanations, I found this ressource:\n> http://www.bitflop.com/document/111\n\nThat's just a precaution (technically it's not necessary, just stops\nyou from doing some dumb things). Suppose the following scenario:\n\n* non-bare repository A, with branch 'master' currently checked out.\n* clone B -> somebody's working on branch 'master' (which was forked \n from A's master)\n* on A, somebody did some local changes\n* meanwhile somebody pushes the branch 'master' from B to A\n* after that, on A, new commit to 'master'.\n\nWeird things can happen, eg. the changes coming from B completely\nreverted by the new commit in A.\n\nUnless nobody pushes to the branch currently checked and later somebody\ndoing local changes after that, there shouldn't be any real technical\nproblem. But then, you most likely wont need an worktree anyways.\n\nWait, there *is* an usecase for such things, deploying trees (eg. webapps)\nsome server:\n\n * application is developed in git\n * the final production-system tree is maintained in certian branch\n * a post-update hook acts on a specific production branch and does\n something like git checkout --detach \n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"202746","messageId":"CAC80649467C483086BB0C33A0BF2747@PhilipOakley","threadId":"32039","inReplyTo":"e4dc73e8-69f9-4695-b8f7-cbc0f04e8197@zcs","subject":"Re: bare vs non-bare <1.7 then >=1.7 ?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2012-11-10T10:29:33Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Enrico Weigelt\" Sent: Saturday, November \n10, 2012 8:23 AM\n\n> Wait, there *is* an usecase for such things, deploying trees (eg. \n> webapps)\n> some server:\n>\n> * application is developed in git\n> * the final production-system tree is maintained in certian branch\n> * a post-update hook acts on a specific production branch and does\n> something like git checkout --detach \n>\nI have an alternative use-case for un-trained collegues :\n\nThe network shared drive has master checked out, and the .git directory \nis hidden. Untrained colleagues don't know I have it as a git remote. \nEven if they show hidden directories they will tend to ignore it as \nbeing just another spurious directory.\n\nI develop on my own box (local directory) on my own branch 'Philip' and \nfeatures therefrom. I push my development history back to the network \nremote to act as a backup. Because I don't touch master I can normally \npush to it quite happily.\n\nWhen I have some finished work I can change to 'working' on the network \ndrive, and merge or rebase my 'Philip' branch into master, and update \nthe network's working tree. The untrained folk now see the new updated \nfiles as if I'd simply worked on / copied into the network share and \nthey are non the wiser (yet) that I do have proper (micro managed) \nhistory.\n\nI can also capture any changes they made to the network share so can go \nback to a point in history when required. It's in matlab and is not a \nbig code base.\n\nPhilip \n"}]}