{"thread":{"id":"10827","subject":"What is the idea for bare repositories?","startedAt":"2007-11-12T13:11:58Z","lastAt":"2007-11-18T03:25:48Z","messageCount":68,"participants":["David Kastrup","Bruno Cesar Ribas","Johannes Schindelin","David Tweed","Jan Wielemaker","Jakub Narebski","Matthieu Moy","Bill Lear","Nicolas Pitre","Andreas Ericsson","Junio C Hamano","Shawn O. Pearce","Jeff King","Brian Gernhardt","Sergei Organov","Wincent Colaiuta"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"59482","messageId":"86k5on8v6p.fsf@lola.quinscape.zz","threadId":"10827","inReplyTo":null,"subject":"What is the idea for bare repositories?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-12T13:11:58Z","receivedAt":"2007-11-12T13:11:58Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nHi,\n\nI have a repository declared as bare. Some commands treat it as such,\nother's don't. For example, I get\n\ngit-diff [no complaint]\ngit-status\nfatal: /usr/local/bin/git-status cannot be used without a working tree.\ngit-reset [no complaint]\ngit-reset --hard\nHEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE\ngit-commit\nfatal: /usr/local/bin/git-commit cannot be used without a working tree.\ngit-add\nfatal: This operation must be run in a work tree\n\nSo this is all somewhat inconsistent. What is the situation supposed\nto be?\n\n-- \nDavid Kastrup\n"},{"id":"59483","messageId":"20071112131927.GA1701@c3sl.ufpr.br","threadId":"10827","inReplyTo":"86k5on8v6p.fsf@lola.quinscape.zz","subject":"Re: What is the idea for bare repositories?","fromName":"Bruno Cesar Ribas","fromEmail":"ribas@c3sl.ufpr.br","sentAt":"2007-11-12T13:19:27Z","receivedAt":"2007-11-12T13:19:27Z","isPatch":false,"sender":{"key":"ribas@c3sl.ufpr.br","avatar":null},"body":"A bare repository is the way to publish your changes to the public.\ngit-daemon and http-clones use a bare repository that only contains\nadminsitrative files.\n\n>From man page\n --bare Make a bare GIT repository. That is, instead of creating\n and placing the administrative files in\n /.git, make the itself the $GIT_DIR. This\n obviously implies the -n because there is nowhere to check out\n the working tree. Also the branch heads at the remote are copied\n directly to corresponding local branch heads, without mapping\n them to refs/remotes/origin/. When this option is used, neither\n remote-tracking branches nor the related configuration variables\n are created.\n\nOn Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:\n> \n> Hi,\n> \n> I have a repository declared as bare. Some commands treat it as such,\n> other's don't. For example, I get\n> \n> git-diff [no complaint]\n> git-status\n> fatal: /usr/local/bin/git-status cannot be used without a working tree.\n> git-reset [no complaint]\n> git-reset --hard\n> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE\n> git-commit\n> fatal: /usr/local/bin/git-commit cannot be used without a working tree.\n> git-add\n> fatal: This operation must be run in a work tree\n> \n> So this is all somewhat inconsistent. What is the situation supposed\n> to be?\n> \n> -- \n> David Kastrup\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n-- \nBruno Ribas - ribas@c3sl.ufpr.br\nhttp://web.inf.ufpr.br/ribas\nC3SL: http://www.c3sl.ufpr.br \n"},{"id":"59485","messageId":"Pine.LNX.4.64.0711121355380.4362@racer.site","threadId":"10827","inReplyTo":"20071112131927.GA1701@c3sl.ufpr.br","subject":"Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T13:57:19Z","receivedAt":"2007-11-12T13:57:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Bruno Cesar Ribas wrote:\n\n> A bare repository is the way to publish your changes to the public. \n> git-daemon and http-clones use a bare repository that only contains \n> adminsitrative files.\n\nMore to the point, a bare repository is one which does not have a working \ndirectory attached.\n\nAs such, many commands do not make any sense at all, such as \"git add\" \n(_what_ do you want to add? There is not even a working directory to work \nwith!), or \"git commit\".\n\nCiao,\nDscho\n"},{"id":"59489","messageId":"e1dab3980711120620l61d3e84ene094ea9235af5a15@mail.gmail.com","threadId":"10827","inReplyTo":"20071112131927.GA1701@c3sl.ufpr.br","subject":"Re: What is the idea for bare repositories?","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2007-11-12T14:20:23Z","receivedAt":"2007-11-12T14:20:23Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"On Nov 12, 2007 1:19 PM, Bruno Cesar Ribas wrote:\n> A bare repository is the way to publish your changes to the public.\n\nJust to mention this: an incredibly minor use, but a bare repository\nis also useful for \"temporary storage\" on a non-case-preserving\nfilesystem (particularly if you don't have the authority/capability to\nchange the filesystem for one that is case preserving).\n\n[I have a USB stick that I also occasionally use on Windows so\ncouldn't reformat. My repo doesn't have files whose names differ only\nby case, but does have files with capitals somewhere. Not caring\neither way about having checked out files, I initially tried to put a\nstandard repo on the stick and it wouldn't fast-forward when I tried\nto push an update to it because some files checked out files had\n\"vanished\". Making it a bare repository avoided the issue problem.]\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"we had no idea that when we added templates we were adding a Turing-\ncomplete compile-time language.\" -- C++ standardisation committee\n"},{"id":"59513","messageId":"86pryf7815.fsf@lola.quinscape.zz","threadId":"10827","inReplyTo":"20071112131927.GA1701@c3sl.ufpr.br","subject":"Re: What is the idea for bare repositories?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-12T16:17:26Z","receivedAt":"2007-11-12T16:17:26Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Bruno Cesar Ribas writes:\n\n> A bare repository is the way to publish your changes to the public.\n> git-daemon and http-clones use a bare repository that only contains\n> adminsitrative files.\n>\n> From man page\n> --bare Make a bare GIT repository. That is, instead of creating\n> and placing the administrative files in\n> /.git, make the itself the $GIT_DIR. This\n> obviously implies the -n because there is nowhere to check out\n> the working tree. Also the branch heads at the remote are copied\n> directly to corresponding local branch heads, without mapping\n> them to refs/remotes/origin/. When this option is used, neither\n> remote-tracking branches nor the related configuration variables\n> are created.\n\nFine. So why don't the following commands complain? Apart from\ngit-reset without arguments (which could probably get along without a\nworking dir), they are supposed to employ a working directory.\n\n> On Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:\n>> \n>> I have a repository declared as bare. Some commands treat it as such,\n>> other's don't. For example, I get\n>> \n>> git-diff [no complaint]\n>> git-reset [no complaint]\n>> git-reset --hard\n>> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE\n\n\n-- \nDavid Kastrup\n"},{"id":"59515","messageId":"200711121719.54146.wielemak@science.uva.nl","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121355380.4362@racer.site","subject":"Re: What is the idea for bare repositories?","fromName":"Jan Wielemaker","fromEmail":"wielemak@science.uva.nl","sentAt":"2007-11-12T16:19:54Z","receivedAt":"2007-11-12T16:19:54Z","isPatch":false,"sender":{"key":"wielemak@science.uva.nl","avatar":null},"body":"On Monday 12 November 2007 14:57, Johannes Schindelin wrote:\n> Hi,\n>\n> On Mon, 12 Nov 2007, Bruno Cesar Ribas wrote:\n> > A bare repository is the way to publish your changes to the public.\n> > git-daemon and http-clones use a bare repository that only contains\n> > adminsitrative files.\n>\n> More to the point, a bare repository is one which does not have a working\n> directory attached.\n>\n> As such, many commands do not make any sense at all, such as \"git add\"\n> (_what_ do you want to add? There is not even a working directory to work\n> with!), or \"git commit\".\n\nAs we are on the subject anyway. Though not tested with the very latest,\nbut when I was playing with them, I found out that cloning a empty bare\nrepository produces nothing at all, dispite the promising message:\n\n\t$ mkdir x && cd x\n\t$ git --bare init --shared=group\n\tInitialized empty shared Git repository in /home/nobackup/jan/tmp/x/\n\t$ cd ..\n\t$ git clone x y\n\tInitialized empty Git repository in /home/jan/nobackup/tmp/y/.git/\n\t$ ls y\n\tls: cannot access y: No such file or directory\n\nIs this a bug?\n\n\t--- Jan\n"},{"id":"59517","messageId":"Pine.LNX.4.64.0711121624330.4362@racer.site","threadId":"10827","inReplyTo":"200711121719.54146.wielemak@science.uva.nl","subject":"Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T16:34:46Z","receivedAt":"2007-11-12T16:34:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Jan Wielemaker wrote:\n\n> I found out that cloning a empty bare repository produces nothing at \n> all, [...]\n\nIf they are empty, what exactly do you mean to clone?\n\nCiao,\nDscho\n"},{"id":"59520","messageId":"fh9vgu$u75$1@ger.gmane.org","threadId":"10827","inReplyTo":"86pryf7815.fsf@lola.quinscape.zz","subject":"Re: What is the idea for bare repositories?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-12T16:37:50Z","receivedAt":"2007-11-12T16:37:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Kastrup wrote:\n\n> Bruno Cesar Ribas writes:\n> \n>> A bare repository is the way to publish your changes to the public.\n>> git-daemon and http-clones use a bare repository that only contains\n>> adminsitrative files.\n[...]\n> \n> Fine. So why don't the following commands complain? Apart from\n> git-reset without arguments (which could probably get along without a\n> working dir), they are supposed to employ a working directory.\n> \n>> On Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:\n>>> \n>>> I have a repository declared as bare. Some commands treat it as such,\n>>> other's don't. For example, I get\n>>> \n>>> git-diff [no complaint]\n>>> git-reset [no complaint]\n>>> git-reset --hard\n>>> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE\n\ngit-diff can compare tree and tree, or tree and index; only for\ncomparing tree and files of index and files it needs working dir.\n\ngit-reset resets only refs and index. git-reset --hard resets also\nfiles, so it needs working directory. Perhaps it should fail completely\nand not only after doing mixed (non-hard) reset if we are in bare\nrepository.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"59522","messageId":"fh9vja$u75$2@ger.gmane.org","threadId":"10827","inReplyTo":"200711121719.54146.wielemak@science.uva.nl","subject":"Re: What is the idea for bare repositories?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-12T16:39:06Z","receivedAt":"2007-11-12T16:39:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jan Wielemaker wrote:\n\n> As we are on the subject anyway. Though not tested with the very latest,\n> but when I was playing with them, I found out that cloning a empty bare\n> repository produces nothing at all, dispite the promising message:\n> \n>         $ mkdir x && cd x\n>         $ git --bare init --shared=group\n\nNote that \"git --bare init\" and \"git init --bare\" are two *different*\nthings (first is no-op, by the way).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"59523","messageId":"vpq3avbv2ju.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121624330.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-12T16:41:57Z","receivedAt":"2007-11-12T16:41:57Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Mon, 12 Nov 2007, Jan Wielemaker wrote:\n>\n>> I found out that cloning a empty bare repository produces nothing at \n>> all, [...]\n>\n> If they are empty, what exactly do you mean to clone?\n\nI'd expect an empty repository, with the git remote configured\ncorrectly.\n\nI already mentionned this here (but didn't take time to write a\npatch), a typical use-case is when I want to create a new project. I'd\nlike to initialize an empty bare repo on my backed up disk, and then\nclone it to my local-fast-unreliable disk to get a working copy and do\nthe first commit there.\n\nCurrently, I have to create both independantly, and configure the\nremote myself. Not terrible, but not conveinient either ;-).\n\n-- \nMatthieu\n"},{"id":"59528","messageId":"86abpj76be.fsf@lola.quinscape.zz","threadId":"10827","inReplyTo":"fh9vgu$u75$1@ger.gmane.org","subject":"Re: What is the idea for bare repositories?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-12T16:54:29Z","receivedAt":"2007-11-12T16:54:29Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jakub Narebski writes:\n\n> David Kastrup wrote:\n>\n>> Bruno Cesar Ribas writes:\n>> \n>>> A bare repository is the way to publish your changes to the public.\n>>> git-daemon and http-clones use a bare repository that only contains\n>>> adminsitrative files.\n> [...]\n>> \n>> Fine. So why don't the following commands complain? Apart from\n>> git-reset without arguments (which could probably get along without a\n>> working dir), they are supposed to employ a working directory.\n>> \n>>> On Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:\n>>>> \n>>>> I have a repository declared as bare. Some commands treat it as such,\n>>>> other's don't. For example, I get\n>>>> \n>>>> git-diff [no complaint]\n>>>> git-reset [no complaint]\n>>>> git-reset --hard\n>>>> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE\n>\n> git-diff can compare tree and tree, or tree and index; only for\n> comparing tree and files of index and files it needs working dir.\n\nWell, if called without arguments (as above), it compares tree and\nindex. So it should complain about not having a tree. It doesn't.\n\n> git-reset resets only refs and index. git-reset --hard resets also\n> files, so it needs working directory. Perhaps it should fail\n> completely and not only after doing mixed (non-hard) reset if we are\n> in bare repository.\n\nPlease reread the above: it does not fail at all. Neither before nor\nafter the mixed reset.\n\n-- \nDavid Kastrup\n"},{"id":"59530","messageId":"Pine.LNX.4.64.0711121715090.4362@racer.site","threadId":"10827","inReplyTo":"vpq3avbv2ju.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T17:15:51Z","receivedAt":"2007-11-12T17:15:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Matthieu Moy wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Mon, 12 Nov 2007, Jan Wielemaker wrote:\n> >\n> >> I found out that cloning a empty bare repository produces nothing at \n> >> all, [...]\n> >\n> > If they are empty, what exactly do you mean to clone?\n> \n> I'd expect an empty repository, with the git remote configured \n> correctly.\n\nYeah, right.\n\nLast time I checked, those geneticists did not clone thin air. They \nalways waited until they had something to clone.\n\nCiao,\nDscho\n"},{"id":"59532","messageId":"18232.35893.243300.179076@lisa.zopyra.com","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121715090.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-11-12T17:24:05Z","receivedAt":"2007-11-12T17:24:05Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, November 12, 2007 at 17:15:51 (+0000) Johannes Schindelin writes:\n>Hi,\n>\n>On Mon, 12 Nov 2007, Matthieu Moy wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > On Mon, 12 Nov 2007, Jan Wielemaker wrote:\n>> >\n>> >> I found out that cloning a empty bare repository produces nothing at \n>> >> all, [...]\n>> >\n>> > If they are empty, what exactly do you mean to clone?\n>> \n>> I'd expect an empty repository, with the git remote configured \n>> correctly.\n>\n>Yeah, right.\n>\n>Last time I checked, those geneticists did not clone thin air. They \n>always waited until they had something to clone.\n\nWe have wanted this behavior; I don't think it's so foolish. We have\nan administrator create a new bare repo for us, and we populate it by\npushing into it. It wold be nice if the administrator could create a\nbare repo and we could clone from it, and push to it to populate it,\ninstead of cloning the bare repo from another repo that has already\nbeen (partly) populated.\n\n\nBill\n"},{"id":"59535","messageId":"Pine.LNX.4.64.0711121727130.4362@racer.site","threadId":"10827","inReplyTo":"18232.35893.243300.179076@lisa.zopyra.com","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T17:30:10Z","receivedAt":"2007-11-12T17:30:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Bill Lear wrote:\n\n> We have an administrator create a new bare repo for us, and we populate \n> it by pushing into it. It wold be nice if the administrator could \n> create a bare repo and we could clone from it, and push to it to \n> populate it, instead of cloning the bare repo from another repo that has \n> already been (partly) populated.\n\nI don't see what is soooo hard with using git-remote in the repo you are \npushing from. It's just a \"git remote add origin \", and you can even \nuse this to push right afterwards: \"git push --all origin\".\n\nBesides, if you really want to work together, chances are that you do \n_not_ want to start with independent initial commits. So you need to \npopulate the repository before starting _anyway_.\n\nWhy are easy solutions so unattractive?\n\nCiao,\nDscho\n"},{"id":"59536","messageId":"86ve875pzh.fsf@lola.quinscape.zz","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121715090.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-12T17:32:34Z","receivedAt":"2007-11-12T17:32:34Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Mon, 12 Nov 2007, Matthieu Moy wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > On Mon, 12 Nov 2007, Jan Wielemaker wrote:\n>> >\n>> >> I found out that cloning a empty bare repository produces nothing at \n>> >> all, [...]\n>> >\n>> > If they are empty, what exactly do you mean to clone?\n>> \n>> I'd expect an empty repository, with the git remote configured \n>> correctly.\n>\n> Yeah, right.\n>\n> Last time I checked, those geneticists did not clone thin air. They \n> always waited until they had something to clone.\n\n>> >> a empty bare repository produces nothing at \n>> >> all, [...]\n>> >\n>> > If they are empty, what exactly do you mean to clone?\n>> \n>> I'd expect an empty repository, with the git remote configured \n>> correctly.\n>\n> Yeah, right.\n>\n> Last time I checked, those geneticists did not clone thin air. They \n> always waited until they had something to clone.\n\ngit-init does not perform sexual intercourse, either. I don't see why\ngeneticists should be relevant for determining what git-clone does.\n\n\n-- \nDavid Kastrup\n"},{"id":"59538","messageId":"alpine.LFD.0.9999.0711121231150.21255@xanadu.home","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121715090.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-12T17:33:08Z","receivedAt":"2007-11-12T17:33:08Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 12 Nov 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Mon, 12 Nov 2007, Matthieu Moy wrote:\n> \n> > Johannes Schindelin writes:\n> > \n> > > On Mon, 12 Nov 2007, Jan Wielemaker wrote:\n> > >\n> > >> I found out that cloning a empty bare repository produces nothing at \n> > >> all, [...]\n> > >\n> > > If they are empty, what exactly do you mean to clone?\n> > \n> > I'd expect an empty repository, with the git remote configured \n> > correctly.\n> \n> Yeah, right.\n> \n> Last time I checked, those geneticists did not clone thin air. They \n> always waited until they had something to clone.\n\nBut we're not geneticists, and I think the above usage should\n\"just work (tm)\".\n\n\nNicolas\n"},{"id":"59547","messageId":"vpq7iknqrtp.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121727130.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-12T17:47:14Z","receivedAt":"2007-11-12T17:47:14Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> I don't see what is soooo hard with using git-remote in the repo you are \n> pushing from. It's just a \"git remote add origin \", and you can even \n> use this to push right afterwards: \"git push --all origin\".\n\nIf \"git remote add\" is so easy, why does \"git clone\" set up the remote\nfor you?\n\nAnd don't tell me that you didn't notice that \"git clone\" does more\nthan your proposed \"git remote add origin ...\".\n\n> Besides, if you really want to work together, chances are that you do \n> _not_ want to start with independent initial commits.\n\nSo, what?\n\n> So you need to populate the repository before starting _anyway_.\n\nLast time I checked, the thread was talking about bare repository.\nPerhaps you have a magic formula to populate a bare repository without\npushing to it from another repo, but I don't.\n\n-- \nMatthieu\n"},{"id":"59540","messageId":"Pine.LNX.4.64.0711121751100.4362@racer.site","threadId":"10827","inReplyTo":"alpine.LFD.0.9999.0711121231150.21255@xanadu.home","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T17:54:23Z","receivedAt":"2007-11-12T17:54:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Nicolas Pitre wrote:\n\n> On Mon, 12 Nov 2007, Johannes Schindelin wrote:\n> \n> > On Mon, 12 Nov 2007, Matthieu Moy wrote:\n> > \n> > > Johannes Schindelin writes:\n> > > \n> > > > On Mon, 12 Nov 2007, Jan Wielemaker wrote:\n> > > >\n> > > >> I found out that cloning a empty bare repository produces nothing \n> > > >> at all, [...]\n> > > >\n> > > > If they are empty, what exactly do you mean to clone?\n> > > \n> > > I'd expect an empty repository, with the git remote configured \n> > > correctly.\n> > \n> > Yeah, right.\n> > \n> > Last time I checked, those geneticists did not clone thin air. They \n> > always waited until they had something to clone.\n> \n> But we're not geneticists, and I think the above usage should \"just work \n> (tm)\".\n\nI am still convinced that it is not very intelligent to start your \ndevelopment from a non-existing branch.\n\nBut since you're one of the people knowing git _internals_ pretty well, \nhere's another reason just for you why this cannot be done: There is no \nway to find out where the HEAD points to.\n\nTry it. Create an empty repository. Then call \"git ls-remote \" on \nit. It's _empty_.\n\nCiao,\nDscho \"who is bored with this discussion\"\n"},{"id":"59541","messageId":"18232.37763.897729.895378@lisa.zopyra.com","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121727130.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-11-12T17:55:15Z","receivedAt":"2007-11-12T17:55:15Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, November 12, 2007 at 17:30:10 (+0000) Johannes Schindelin writes:\n>Hi,\n>\n>On Mon, 12 Nov 2007, Bill Lear wrote:\n>\n>> We have an administrator create a new bare repo for us, and we populate \n>> it by pushing into it. It wold be nice if the administrator could \n>> create a bare repo and we could clone from it, and push to it to \n>> populate it, instead of cloning the bare repo from another repo that has \n>> already been (partly) populated.\n>\n>I don't see what is soooo hard with using git-remote in the repo you are \n>pushing from. It's just a \"git remote add origin \", and you can even \n>use this to push right afterwards: \"git push --all origin\".\n>\n>Besides, if you really want to work together, chances are that you do \n>_not_ want to start with independent initial commits. So you need to \n>populate the repository before starting _anyway_.\n>\n>Why are easy solutions so unattractive?\n\nWell, 1) to answer your first point: it's not soooo hard, but it's an\nextra step that just seems unnecessary. 2) It's not the *easiest*\nsolution that one can think of, so people naturally complain: \"why do\nI have to push in the clutch AND select the gear\"?\n\n\nBill\n"},{"id":"59542","messageId":"Pine.LNX.4.64.0711121755460.4362@racer.site","threadId":"10827","inReplyTo":"vpq7iknqrtp.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T17:57:32Z","receivedAt":"2007-11-12T17:57:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Matthieu Moy wrote:\n\n> Johannes Schindelin writes:\n> \n> > So you need to populate the repository before starting _anyway_.\n> \n> Last time I checked, the thread was talking about bare repository. \n\nWrong. Wrong, wrong, wrong.\n\nIt was talking about _cloning_ an _empty_ repository. (Bare or not is not \ninteresting in this context.)\n\n> Perhaps you have a magic formula to populate a bare repository without \n> pushing to it from another repo, but I don't.\n\nNo, but that was not what I was questioning. No, sir, not at all.\n\nCiao,\nDscho\n"},{"id":"59543","messageId":"vpqy7d3pck0.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121755460.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-12T18:02:23Z","receivedAt":"2007-11-12T18:02:23Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Mon, 12 Nov 2007, Matthieu Moy wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > So you need to populate the repository before starting _anyway_.\n>> \n>> Last time I checked, the thread was talking about bare repository. \n>\n> Wrong. Wrong, wrong, wrong.\n\nRepeating it 4 times doesn't make it correct. You can even try 5\ntimes, it won't change.\n\nGrep for \"bare\" in the following text:\n\n,----\n| Hi,\n| \n| On Mon, 12 Nov 2007, Jan Wielemaker wrote:\n| \n| > I found out that cloning a empty bare repository produces nothing at \n| > all, [...]\n| \n| If they are empty, what exactly do you mean to clone?\n| \n| Ciao,\n| Dscho\n`----\n\nAnd then, guess how I ended-up with that text (hint : cut-and-paste).\n\n>> Perhaps you have a magic formula to populate a bare repository without \n>> pushing to it from another repo, but I don't.\n>\n> No, but that was not what I was questioning. No, sir, not at all.\n\nPerhaps you can reconsider this after reading the above.\n\n-- \nMatthieu\n"},{"id":"59544","messageId":"Pine.LNX.4.64.0711121804400.4362@racer.site","threadId":"10827","inReplyTo":"vpqy7d3pck0.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T18:06:13Z","receivedAt":"2007-11-12T18:06:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nHi,\n\n> > On Mon, 12 Nov 2007, Matthieu Moy wrote:\n> >\n> >> Johannes Schindelin writes:\n> >> \n> >> > So you need to populate the repository before starting _anyway_.\n> >> \n> >> Last time I checked, the thread was talking about bare repository.\n\nLook at the subject. \"Cloning empty repositories.\"\n\nNuff said,\nDscho who sighs\n"},{"id":"59545","messageId":"vpqoddzpc88.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121804400.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-12T18:09:27Z","receivedAt":"2007-11-12T18:09:27Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n>> > On Mon, 12 Nov 2007, Matthieu Moy wrote:\n>> >\n>> >> Johannes Schindelin writes:\n>> >> \n>> >> > So you need to populate the repository before starting _anyway_.\n>> >> \n>> >> Last time I checked, the thread was talking about bare repository.\n>\n> Look at the subject. \"Cloning empty repositories.\"\n\nLook at the content. \"cloning a empty bare repository\".\n\nI insist that the content is the content that _YOU_ quoted, which is\nthe starting point of the discussion.\n\n-- \nMatthieu -- who finds it hard to discuss with people only reading\n subject in emails.\n"},{"id":"59546","messageId":"alpine.LFD.0.9999.0711121309400.21255@xanadu.home","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121751100.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-12T18:16:21Z","receivedAt":"2007-11-12T18:16:21Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 12 Nov 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Mon, 12 Nov 2007, Nicolas Pitre wrote:\n> \n> > On Mon, 12 Nov 2007, Johannes Schindelin wrote:\n> > \n> > > Last time I checked, those geneticists did not clone thin air. They \n> > > always waited until they had something to clone.\n> > \n> > But we're not geneticists, and I think the above usage should \"just work \n> > (tm)\".\n> \n> I am still convinced that it is not very intelligent to start your \n> development from a non-existing branch.\n\nWell, that's an orthogonal question and I'm not providing any opinion \nabout that.\n\n> But since you're one of the people knowing git _internals_ pretty well, \n> here's another reason just for you why this cannot be done: There is no \n> way to find out where the HEAD points to.\n\nSo? Why couldn't you just do the 'git remote add' dance implicitly in \nthat case anyway?\n\n\nNicolas\n"},{"id":"59549","messageId":"200711121955.42154.wielemak@science.uva.nl","threadId":"10827","inReplyTo":"vpq7iknqrtp.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Jan Wielemaker","fromEmail":"wielemak@science.uva.nl","sentAt":"2007-11-12T18:55:41Z","receivedAt":"2007-11-12T18:55:41Z","isPatch":false,"sender":{"key":"wielemak@science.uva.nl","avatar":null},"body":"On Monday 12 November 2007 18:47:14 Matthieu Moy wrote:\n> Johannes Schindelin writes:\n> > I don't see what is soooo hard with using git-remote in the repo you are\n> > pushing from. It's just a \"git remote add origin \", and you can\n> > even use this to push right afterwards: \"git push --all origin\".\n>\n> If \"git remote add\" is so easy, why does \"git clone\" set up the remote\n> for you?\n>\n> And don't tell me that you didn't notice that \"git clone\" does more\n> than your proposed \"git remote add origin ...\".\n>\n> > Besides, if you really want to work together, chances are that you do\n> > _not_ want to start with independent initial commits.\n>\n> So, what?\n>\n> > So you need to populate the repository before starting _anyway_.\n>\n> Last time I checked, the thread was talking about bare repository.\n> Perhaps you have a magic formula to populate a bare repository without\n> pushing to it from another repo, but I don't.\n\nHey guys, don't fight about the details. Just stick to\n\n\t* Creating a bare empty repositiory is possible and a perfectly\n\tvalid way to create a shared repositiory.\n\t* Clone and push is the natural way to modify it. At least to\n\tme this was the obvious thing to do. Explicitely playing with\n\tremotes is -as far as i'm concerned- lesson 2.\n\t* If this cannot be done (but, what is wrong with an empty tree?)\n\tat least\n\t\t- git clone should *not* say it created a repository\n\t\t- The documentation should have a note on that\n\n\tCheers --- Jan\n"},{"id":"59553","messageId":"4738A6BD.50704@op5.se","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711121751100.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-12T19:17:17Z","receivedAt":"2007-11-12T19:17:17Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 12 Nov 2007, Nicolas Pitre wrote:\n> \n>> On Mon, 12 Nov 2007, Johannes Schindelin wrote:\n>>\n>>> On Mon, 12 Nov 2007, Matthieu Moy wrote:\n>>>\n>>>> Johannes Schindelin writes:\n>>>>\n>>>>> On Mon, 12 Nov 2007, Jan Wielemaker wrote:\n>>>>>\n>>>>>> I found out that cloning a empty bare repository produces nothing \n>>>>>> at all, [...]\n>>>>> If they are empty, what exactly do you mean to clone?\n>>>> I'd expect an empty repository, with the git remote configured \n>>>> correctly.\n>>> Yeah, right.\n>>>\n>>> Last time I checked, those geneticists did not clone thin air. They \n>>> always waited until they had something to clone.\n>> But we're not geneticists, and I think the above usage should \"just work \n>> (tm)\".\n> \n> I am still convinced that it is not very intelligent to start your \n> development from a non-existing branch.\n> \n\nThat's what happens with every new project though. The question is if\nsomething starts with making space for things to be in, or if it starts\nwith things appearing in that space.\n\n> But since you're one of the people knowing git _internals_ pretty well, \n> here's another reason just for you why this cannot be done: There is no \n> way to find out where the HEAD points to.\n> \n\n$ mkdir foo; cd foo; git init; git symbolic-ref -q HEAD\nrefs/heads/master\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"59580","messageId":"7v4pfr2kmh.fsf@gitster.siamese.dyndns.org","threadId":"10827","inReplyTo":"vpqoddzpc88.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-12T21:56:38Z","receivedAt":"2007-11-12T21:56:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Johannes Schindelin writes:\n>\n>>> > On Mon, 12 Nov 2007, Matthieu Moy wrote:\n>>> >\n>>> >> Johannes Schindelin writes:\n>>> >> \n>>> >> > So you need to populate the repository before starting _anyway_.\n>>> >> \n>>> >> Last time I checked, the thread was talking about bare repository.\n>>\n>> Look at the subject. \"Cloning empty repositories.\"\n>\n> Look at the content. \"cloning a empty bare repository\".\n\nBut both of Johannes's points apply equally well to an empty\nbare repository and to an empty non bare repository. IOW,\nbareness does not matter to the suggestion Johannes gave.\n\nBut you are acting as if the bareness of the target repository\nmakes his point irrelevant. I am a bit confused.\n\nAbout his point 1, I'd just stop at saying that \"it is not so\nhard\" does not mean \"we do not have to make it even easier\".\n\nHis second point is also a real issue. If you allowed cloning\nan empty repo (either bare or non-bare), then you and Bill can\nboth clone from it, come up with an initial commit each. Bill\npushes his initial commit first. Your later attempt to push\nwill hopefully fail with \"non fast forward\", if you know better\nthan forcing such a push, but then what? You need to fetch, and\nmerge (or rebase) your change on top of Bill's initial commit,\nand at that point the history you are trying to merge does not\nhave any common ancestor with his history.\n"},{"id":"59581","messageId":"7vzlxj15xe.fsf@gitster.siamese.dyndns.org","threadId":"10827","inReplyTo":"4738A6BD.50704@op5.se","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-12T21:59:25Z","receivedAt":"2007-11-12T21:59:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Johannes Schindelin wrote:\n>\n>> But since you're one of the people knowing git _internals_ pretty\n>> well, here's another reason just for you why this cannot be done:\n>> There is no way to find out where the HEAD points to.\n>\n> $ mkdir foo; cd foo; git init; git symbolic-ref -q HEAD\n> refs/heads/master\n\nJohannes is talking about the lack of native protocol support to\ntransfer symref information. That's the reason git-clone dances\naround finding where HEAD really points at. It simply does not\nknow -- all it gets about a symref is what SHA-1 the ref points\nat.\n"},{"id":"59582","messageId":"alpine.LFD.0.9999.0711121702030.21255@xanadu.home","threadId":"10827","inReplyTo":"7v4pfr2kmh.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-12T22:06:01Z","receivedAt":"2007-11-12T22:06:01Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 12 Nov 2007, Junio C Hamano wrote:\n\n> His second point is also a real issue. If you allowed cloning\n> an empty repo (either bare or non-bare), then you and Bill can\n> both clone from it, come up with an initial commit each. Bill\n> pushes his initial commit first. Your later attempt to push\n> will hopefully fail with \"non fast forward\", if you know better\n> than forcing such a push, but then what? You need to fetch, and\n> merge (or rebase) your change on top of Bill's initial commit,\n> and at that point the history you are trying to merge does not\n> have any common ancestor with his history.\n\nWhile that could well be true, I don't see this condition happening \nsolely in the context (hence because) of an empty clone.\n\n\nNicolas\n"},{"id":"59585","messageId":"Pine.LNX.4.64.0711122212540.4362@racer.site","threadId":"10827","inReplyTo":"alpine.LFD.0.9999.0711121702030.21255@xanadu.home","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T22:17:52Z","receivedAt":"2007-11-12T22:17:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Nicolas Pitre wrote:\n\n> On Mon, 12 Nov 2007, Junio C Hamano wrote:\n> \n> > His second point is also a real issue. If you allowed cloning\n> > an empty repo (either bare or non-bare), then you and Bill can\n> > both clone from it, come up with an initial commit each. Bill\n> > pushes his initial commit first. Your later attempt to push\n> > will hopefully fail with \"non fast forward\", if you know better\n> > than forcing such a push, but then what? You need to fetch, and\n> > merge (or rebase) your change on top of Bill's initial commit,\n> > and at that point the history you are trying to merge does not\n> > have any common ancestor with his history.\n> \n> While that could well be true, I don't see this condition happening \n> solely in the context (hence because) of an empty clone.\n\nHehe. That is a very delicate play with predicates.\n\nIf Alice and Bob clone from an empty repository, and both work on it, \nthere is _no way_ that they can have a common ancestor[*]. Hence, an \nempty clone _would_ be a cause of that condition.\n\nThe only way to _not_ have this condition would be at least one side \nstarting with a non-empty clone. Or with an _effectively_ non-empty \nclone.\n\nCiao,\nDscho\n\n[*] Oh yes, theoretically they could commit the same commit with the same \nauthor info and author timestamp, but to be a common ancestor, they would \nalso have to use the same _committer_information, which means that Alice \n== Bob, as far as Git is concerned. Do I have to go on?\n"},{"id":"59592","messageId":"fhalah$e9s$1@ger.gmane.org","threadId":"10827","inReplyTo":"7vzlxj15xe.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-12T22:49:55Z","receivedAt":"2007-11-12T22:49:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson writes:\n>> Johannes Schindelin wrote:\n>>\n>>> But since you're one of the people knowing git _internals_ pretty\n>>> well, here's another reason just for you why this cannot be done:\n>>> There is no way to find out where the HEAD points to.\n>>\n>> $ mkdir foo; cd foo; git init; git symbolic-ref -q HEAD\n>> refs/heads/master\n> \n> Johannes is talking about the lack of native protocol support to\n> transfer symref information. That's the reason git-clone dances\n> around finding where HEAD really points at. It simply does not\n> know -- all it gets about a symref is what SHA-1 the ref points\n> at.\n\nDo I remember correctly that there was some talk about extending git\nprotocol to avoid this compicated dance, and transfer symbolic refs\ndirectly?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"59602","messageId":"4738EC25.20108@op5.se","threadId":"10827","inReplyTo":"7v4pfr2kmh.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-13T00:13:25Z","receivedAt":"2007-11-13T00:13:25Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> His second point is also a real issue. If you allowed cloning\n> an empty repo (either bare or non-bare), then you and Bill can\n> both clone from it, come up with an initial commit each. Bill\n> pushes his initial commit first. Your later attempt to push\n> will hopefully fail with \"non fast forward\", if you know better\n> than forcing such a push, but then what? You need to fetch, and\n> merge (or rebase) your change on top of Bill's initial commit,\n> and at that point the history you are trying to merge does not\n> have any common ancestor with his history.\n\n\nIf we assume zero communication between these two, the alternative\nis this:\nBill starts hacking in his own repo and then uploads his .git dir\nto the server.\nDavid starts hacking in his own repo and then uploads his .git\ndir to the server.\n\nThe only difference between the two scenarios is (assuming they\nhave write access to those shared directories) that the last-in\nwins in the second case, while first-in wins in the first one.\n\nOh, and the fact that the first to upload his .git dir to the\nserver will lose all his refs if he isn't careful to save his\noriginal copy until they both have established which \"first\"\ncommit to use, which could take a while in this imaginary world\nwhere they don't seem to be speaking to each other but are still\nworking together.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"59639","messageId":"vpqzlxiiii6.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"7v4pfr2kmh.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-13T09:48:01Z","receivedAt":"2007-11-13T09:48:01Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> But both of Johannes's points apply equally well to an empty\n> bare repository and to an empty non bare repository. IOW,\n> bareness does not matter to the suggestion Johannes gave.\n\nHe was suggesting to create the initial commit before cloning:\n\n>> So you need to populate the repository before starting _anyway_.\n\nTo create an initial commit in a non-bare repository, I put files in\nit, git add, and git commit.\n\nTo create an initial commit in a bare repository, the most natural way\nfor me is to clone it, create the commit in the clone, and then push.\n\nBare-ness _does_ matter for that.\n\nI repeat the use-case I mentionned above :\n\n,----\n| a typical use-case is when I want to create a new project. I'd\n| like to initialize an empty bare repo on my backed up disk, and then\n| clone it to my local-fast-unreliable disk to get a working copy and do\n| the first commit there.\n`----\n\nI find this quite natural, and up to now, no one gave me either a\nrationale not to do that, or a _simple_ way to achieve this. As I\nsaid, it's currently not _very_ hard to do, but I have to edit\n.git/config by hand, while git clone knows how to do this much faster\nthan I for non-empty repositories.\n\n-- \nMatthieu\n"},{"id":"59643","messageId":"20071113100209.GE14735@spearce.org","threadId":"10827","inReplyTo":"vpqzlxiiii6.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-13T10:02:09Z","receivedAt":"2007-11-13T10:02:09Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Matthieu Moy wrote:\n> I repeat the use-case I mentionned above :\n> \n> ,----\n> | a typical use-case is when I want to create a new project. I'd\n> | like to initialize an empty bare repo on my backed up disk, and then\n> | clone it to my local-fast-unreliable disk to get a working copy and do\n> | the first commit there.\n> `----\n> \n> I find this quite natural, and up to now, no one gave me either a\n> rationale not to do that, or a _simple_ way to achieve this. As I\n> said, it's currently not _very_ hard to do, but I have to edit\n> .git/config by hand, while git clone knows how to do this much faster\n> than I for non-empty repositories.\n\nIts a goal to redefine git-clone as the following, as that is\nreally all it does:\n\n\tmkdir foo && cd foo && git init &&\n\tgit remote add -f origin $url &&\n\tgit checkout -b master origin/master\n\nSo setting up an empty tree is basically that:\n\n\tmkdir foo && cd foo && git init &&\n\tgit remote add origin $url\n\nIs that really so difficult? git-clone is a handy crutch for when\nwe didn't have things like git-remote. Or remote tracking branches.\nIMHO the above may seem a little low level but it may make it easier\nto teach to newbies. They are more likely to grasp the concept of\ntheir repository being just like someone else's, and that they can\ntrack other repositories beyond just their origin.\n\n-- \nShawn.\n"},{"id":"59646","messageId":"fhbt3o$ebf$2@ger.gmane.org","threadId":"10827","inReplyTo":"vpqzlxiiii6.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-13T10:08:56Z","receivedAt":"2007-11-13T10:08:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy wrote:\n\n> I repeat the use-case I mentionned above :\n> \n> ,----\n> | a typical use-case is when I want to create a new project. I'd\n> | like to initialize an empty bare repo on my backed up disk, and then\n> | clone it to my local-fast-unreliable disk to get a working copy and do\n> | the first commit there.\n> `----\n> \n> I find this quite natural, and up to now, no one gave me either a\n> rationale not to do that,\n\nThe rationale is that current git just simply cannot do this.\nYou are welcome to add support for this corner case in git-clone,\nor add git protocol extension for symref transfer.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"59652","messageId":"vpqpryefmhj.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"20071113100209.GE14735@spearce.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-13T10:50:16Z","receivedAt":"2007-11-13T10:50:16Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> So setting up an empty tree is basically that:\n>\n> \tmkdir foo && cd foo && git init &&\n> \tgit remote add origin $url\n\nIt is not.\n\nThe \"git remote add\" thing adds this to my .git/config:\n\n[remote \"origin\"]\n url = /tmp/git1\n fetch = +refs/heads/*:refs/remotes/origin/*\n\nWhile clone normally does a bit more:\n\n[remote \"origin\"]\n url = /tmp/git1/.git\n fetch = +refs/heads/*:refs/remotes/origin/*\n[branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\nSo, it's really\n\n$ git remote add origin url\n$ $EDITOR .git/config # or perhaps I missed the way to set the two\n # options easily.\n\nI find it so conveinient to have it for non-empty clones, it's\nfrustrating to have to do it by hand for empty clones.\n\n-- \nMatthieu\n"},{"id":"59654","messageId":"Pine.LNX.4.64.0711131118360.4362@racer.site","threadId":"10827","inReplyTo":"vpqzlxiiii6.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-13T11:19:29Z","receivedAt":"2007-11-13T11:19:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Nov 2007, Matthieu Moy wrote:\n\n> Junio C Hamano writes:\n> \n> > But both of Johannes's points apply equally well to an empty bare \n> > repository and to an empty non bare repository. IOW, bareness does \n> > not matter to the suggestion Johannes gave.\n> \n> He was suggesting to create the initial commit before cloning:\n> \n> >> So you need to populate the repository before starting _anyway_.\n\nOf course I was suggesting to push into the still empty, bare repository, \nbefore anybody is cloning.\n\nCiao,\nDscho\n"},{"id":"59661","messageId":"20071113114059.GC15845@sigill.intra.peff.net","threadId":"10827","inReplyTo":"vpqpryefmhj.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-13T11:40:59Z","receivedAt":"2007-11-13T11:40:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 13, 2007 at 11:50:16AM +0100, Matthieu Moy wrote:\n\n> The \"git remote add\" thing adds this to my .git/config:\n> \n> [remote \"origin\"]\n> url = /tmp/git1\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> \n> While clone normally does a bit more:\n> \n> [remote \"origin\"]\n> url = /tmp/git1/.git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n\nAlso, git-clone sets up the HEAD symref automagically (you can specify\nit manually with git-remote, but git-clone will put it from the remote's\nHEAD).\n\n-Peff\n"},{"id":"59678","messageId":"alpine.LFD.0.9999.0711131229140.21255@xanadu.home","threadId":"10827","inReplyTo":"20071113100209.GE14735@spearce.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-13T17:34:03Z","receivedAt":"2007-11-13T17:34:03Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 13 Nov 2007, Shawn O. Pearce wrote:\n\n> Matthieu Moy wrote:\n> > I repeat the use-case I mentionned above :\n> > \n> > ,----\n> > | a typical use-case is when I want to create a new project. I'd\n> > | like to initialize an empty bare repo on my backed up disk, and then\n> > | clone it to my local-fast-unreliable disk to get a working copy and do\n> > | the first commit there.\n> > `----\n> > \n> > I find this quite natural, and up to now, no one gave me either a\n> > rationale not to do that, or a _simple_ way to achieve this. As I\n> > said, it's currently not _very_ hard to do, but I have to edit\n> > .git/config by hand, while git clone knows how to do this much faster\n> > than I for non-empty repositories.\n> \n> Its a goal to redefine git-clone as the following, as that is\n> really all it does:\n> \n> \tmkdir foo && cd foo && git init &&\n> \tgit remote add -f origin $url &&\n> \tgit checkout -b master origin/master\n> \n> So setting up an empty tree is basically that:\n> \n> \tmkdir foo && cd foo && git init &&\n> \tgit remote add origin $url\n> \n> Is that really so difficult? git-clone is a handy crutch for when\n> we didn't have things like git-remote. Or remote tracking branches.\n> IMHO the above may seem a little low level but it may make it easier\n> to teach to newbies. They are more likely to grasp the concept of\n> their repository being just like someone else's, and that they can\n> track other repositories beyond just their origin.\n\nFWIW all my Git tutorials for $work so far always avoided 'git clone'. \nThe 'git init' + 'git remote add' + 'git fetch' is what I ask people to \ndo. It is more obvious to give a good name for the remote repo that \nway, and this can be performed into either a new or an existing repo \nwhen the data is related.\n\n\nNicolas\n"},{"id":"59688","messageId":"7vir46t2cc.fsf@gitster.siamese.dyndns.org","threadId":"10827","inReplyTo":"vpqzlxiiii6.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-13T18:41:39Z","receivedAt":"2007-11-13T18:41:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> To create an initial commit in a bare repository, the most natural way\n> for me is to clone it, create the commit in the clone, and then push.\n>\n> Bare-ness _does_ matter for that.\n\nYou are still wrong.\n\nThe most natural is to create a commit in a non-bare repository\nyou create, and push into a bare empty repository. The\nrepository that is pushed into can be non-bare, but bareness of\nthat does _NOT_ matter.\n\nWhere bareness matters is on your end, the local private\nrepository you create the initial commit in.\n"},{"id":"59706","messageId":"CBAEC42B-9F50-4723-9847-640D9832532E@silverinsanity.com","threadId":"10827","inReplyTo":"vpqpryefmhj.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-11-13T19:50:49Z","receivedAt":"2007-11-13T19:50:49Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Nov 13, 2007, at 5:50 AM, Matthieu Moy wrote:\n\n> While clone normally does a bit more:\n>\n> [remote \"origin\"]\n> url = /tmp/git1/.git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n\nBut how is clone expected to do that when the origin is an empty \nrepo? There is no branch for it to track, and automagically setting \nit to master is bogus because then it's tracking something that \ndoesn't exist.\n\nThe easy way to set up the last bit is \"git checkout -b master --track \norigin/master\". But that won't work if origin/master doesn't exist. \nThe following will always work:\n\ngit config branch.master.remote origin\ngit config branch.master.merge refs/heads/master\n\nBut asking git-clone do do this sort of odd magic for an empty repo is \ndubious at best. Perhaps convenient for your situation, but creates \nrepos that don't actually work. (Will give errors when trying to \nmerge a non-existent branch, at the very least.)\n\n~~ Brian\n"},{"id":"59749","messageId":"vpqhcjp6clm.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"CBAEC42B-9F50-4723-9847-640D9832532E@silverinsanity.com","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-13T21:48:37Z","receivedAt":"2007-11-13T21:48:37Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Brian Gernhardt writes:\n\n> On Nov 13, 2007, at 5:50 AM, Matthieu Moy wrote:\n>\n>> While clone normally does a bit more:\n>>\n>> [remote \"origin\"]\n>> url = /tmp/git1/.git\n>> fetch = +refs/heads/*:refs/remotes/origin/*\n>> [branch \"master\"]\n>> remote = origin\n>> merge = refs/heads/master\n>\n> But how is clone expected to do that when the origin is an empty\n> repo? There is no branch for it to track, and automagically setting\n> it to master is bogus because then it's tracking something that\n> doesn't exist.\n\nAn implementation of that would probably need to special-case the\nempty repository. But an empty repository is already a special case.\nHEAD already points to master, and master is already hardcoded here:\n\n$ cat .git/HEAD \nref: refs/heads/master\n\nSo, it's possible for HEAD to point to a branch which doesn't exist\nyet, it's possible to commit to a branch which doesn't exist yet. It\nwould make sense to extend that to allow a remote to point to a branch\nwhich doesn't exist either.\n\nBut don't get me wrong: I probably won't implement that myself, so I\ncan't _ask_ people to do it for me. I would just appreciate if people\nstopped calling me (and other users interested in a sane empty clone\nbehavior) idiot because I think it would make sense to do it.\n\n-- \nMatthieu\n"},{"id":"59756","messageId":"vpqd4ud6c0z.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"7vir46t2cc.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-13T22:01:00Z","receivedAt":"2007-11-13T22:01:00Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> To create an initial commit in a bare repository, the most natural way\n>> for me is to clone it, create the commit in the clone, and then push.\n>>\n>> Bare-ness _does_ matter for that.\n>\n> You are still wrong.\n>\n> The most natural is to create a commit in a non-bare repository\n> you create, and push into a bare empty repository.\n\nYes, we agree on that point.\n\nBut I do find (incorrect with current git)\n\n(1)\n\n$ mkdir ~/bare-repo\n$ cd ~/bare-repo\n$ git --bare init\n$ cd\n$ git clone bare-repo local/non-bare\n$ cd local/non-bare\n\n$ git push\n\nSimpler than (valid with current git)\n\n(2)\n\n$ mkdir ~/bare-repo\n$ cd ~/bare-repo\n$ git --bare init\n$ cd\n$ mkdir local/non-bare\n$ cd local/non-bare\n$ git init\n\n$ git push ~/bare-repo\n$ git remote add origin ~/bare-repo\n$ git config branch.master.remote origin\n$ git config branch.master.merge refs/heads/master\n\nWhere the bare-ness of ~/bare-repo matters is that with a bare\nrepository, I could have actually created the initial commit there\n(valid with current git too):\n\n(3)\n\n$ mkdir ~/non-bare-repo\n$ cd ~/non-bare-repo\n$ git init\n\n$ cd\n$ git clone bare-repo local/non-bare\n\n> The repository that is pushed into can be non-bare, but bareness of\n> that does _NOT_ matter.\n\nEither there is a way to achive (3) above with a bare repository which\nI don't know, or bare-ness does matter in this case.\n\n-- \nMatthieu\n"},{"id":"59767","messageId":"85abph4uw2.fsf@lola.goethe.zz","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711122212540.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-13T22:56:29Z","receivedAt":"2007-11-13T22:56:29Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> If Alice and Bob clone from an empty repository, and both work on it,\n> there is _no way_ that they can have a common ancestor[*]. Hence, an\n> empty clone _would_ be a cause of that condition.\n\nSo where is the problem with that?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"59777","messageId":"Pine.LNX.4.64.0711132352340.4362@racer.site","threadId":"10827","inReplyTo":"vpqhcjp6clm.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-13T23:56:00Z","receivedAt":"2007-11-13T23:56:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Nov 2007, Matthieu Moy wrote:\n\n> I would just appreciate if people stopped calling me (and other users \n> interested in a sane empty clone behavior) idiot because I think it \n> would make sense to do it.\n\nOh, come on. Nobody called _you_ idiot.\n\nBut I illustrated that cloning from an empty repository makes no sense.\n\nThere is a huge difference between calling somebody an idiot on the one \nside, and investing some time to help somebody who has a suboptimal \nworkflow on the other one.\n\nBut I fear that you took my help as a personal attack, and as a \nconsequence you feel insulted, and I wasted my precious time.\n\nCiao,\nDscho\n"},{"id":"59793","messageId":"7vejetr7vn.fsf@gitster.siamese.dyndns.org","threadId":"10827","inReplyTo":"vpqd4ud6c0z.fsf@bauges.imag.fr","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-14T00:25:00Z","receivedAt":"2007-11-14T00:25:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> (2)\n>\n> $ mkdir ~/bare-repo\n> $ cd ~/bare-repo\n> $ git --bare init\n> $ cd\n> $ mkdir local/non-bare\n> $ cd local/non-bare\n> $ git init\n\n...\n\nIf your publishing repo is local like the above, then\n\n $ mkdir /tmp/junk && cd /tmp/junk\n $ git init; tar xf /tmp/project.tar; git add .; ... populate ... \n $ git commit -m initial\n $ cd /else/where/to/publish\n $ git clone --bare /tmp/junk myproject.git\n $ rm -fr /tmp/junk\n\nwould be enough to get your published repository started, isn't\nit? Then wouldn't:\n\n $ cd $HOME\n $ git clone /else/where/to/publish/myproject.git myproject\n\nset up your ~/myproject exactly the same way as other people who\nwill work with that published repository?\n"},{"id":"59834","messageId":"vpqir45w4nh.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711132352340.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-14T09:35:46Z","receivedAt":"2007-11-14T09:35:46Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> But I illustrated that cloning from an empty repository makes no sense.\n\nAnd I, and others, illustrated the opposite.\n\n> There is a huge difference between calling somebody an idiot on the one \n> side, and investing some time to help somebody who has a suboptimal \n> workflow on the other one.\n\nYou didn't show me where my proposed flow was suboptimal.\n\n> But I fear that you took my help as a personal attack, and as a \n> consequence you feel insulted, and I wasted my precious time.\n\nDo you call _that_ \"help\"?\n\n,----\n| Last time I checked, those geneticists did not clone thin air. They \n| always waited until they had something to clone.\n`----\n\nTo me, this classifies either as \"totally irrelevant remark\", or as\n\"making fun of someone\". Definitely not \"help\".\n\n-- \nMatthieu\n"},{"id":"59838","messageId":"vpqbq9xw40s.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"7vejetr7vn.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-14T09:49:23Z","receivedAt":"2007-11-14T09:49:23Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano writes:\n\n> If your publishing repo is local like the above, then\n\nIn my case, it's more often a \"backed-up and slow NFS disk\" Vs \"local\ndisk\" than a matter of publishing, but the result is similar.\n\n> $ mkdir /tmp/junk && cd /tmp/junk\n> $ git init; tar xf /tmp/project.tar; git add .; ... populate ... \n> $ git commit -m initial\n> $ cd /else/where/to/publish\n> $ git clone --bare /tmp/junk myproject.git\n> $ rm -fr /tmp/junk\n>\n> would be enough to get your published repository started, isn't\n> it? Then wouldn't:\n>\n> $ cd $HOME\n> $ git clone /else/where/to/publish/myproject.git myproject\n>\n> set up your ~/myproject exactly the same way as other people who\n> will work with that published repository?\n\nSure, it definitely works. But that (creating a temporary repository,\nand right after, delete it) also is an extra step. Not a huge one, but\nstill an extra step.\n\nTake the same with bzr for example:\n\n$ bzr init ~/repo\n$ bzr checkout ~/repo ~/local/work/\n$ cd ~/local/work/\n\n\n\n(bzr checkout is a bit different from git clone, but the difference it\nnot totally relevant here).\n\nI litterally have just two bzr commands before I can start working\nnormally.\n\n-- \nMatthieu\n"},{"id":"59846","messageId":"87myth58r5.fsf@osv.gnss.ru","threadId":"10827","inReplyTo":"7v4pfr2kmh.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-14T12:09:18Z","receivedAt":"2007-11-14T12:09:18Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Junio C Hamano writes:\n> Matthieu Moy writes:\n>\n>> Johannes Schindelin writes:\n>>\n>>>> > On Mon, 12 Nov 2007, Matthieu Moy wrote:\n>>>> >\n>>>> >> Johannes Schindelin writes:\n>>>> >> \n>>>> >> > So you need to populate the repository before starting _anyway_.\n>>>> >> \n>>>> >> Last time I checked, the thread was talking about bare repository.\n>>>\n>>> Look at the subject. \"Cloning empty repositories.\"\n>>\n>> Look at the content. \"cloning a empty bare repository\".\n>\n> But both of Johannes's points apply equally well to an empty\n> bare repository and to an empty non bare repository. IOW,\n> bareness does not matter to the suggestion Johannes gave.\n>\n> But you are acting as if the bareness of the target repository\n> makes his point irrelevant. I am a bit confused.\n>\n> About his point 1, I'd just stop at saying that \"it is not so\n> hard\" does not mean \"we do not have to make it even easier\".\n>\n> His second point is also a real issue. If you allowed cloning\n> an empty repo (either bare or non-bare), then you and Bill can\n> both clone from it, come up with an initial commit each. Bill\n> pushes his initial commit first. Your later attempt to push\n> will hopefully fail with \"non fast forward\", if you know better\n> than forcing such a push, but then what? You need to fetch, and\n> merge (or rebase) your change on top of Bill's initial commit,\n> and at that point the history you are trying to merge does not\n> have any common ancestor with his history.\n\nJust a wild idea. Doesn't it make sense to introduce perfect ultimate\ncommon ancestor of the universe, probably calling it \"the NULL commit\"?\nAt first glance it seems that it can help to avoid corner cases\nautomagically.\n\n-- \nSergei.\n"},{"id":"59848","messageId":"fhettp$rtk$1@ger.gmane.org","threadId":"10827","inReplyTo":"87myth58r5.fsf@osv.gnss.ru","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-14T13:41:13Z","receivedAt":"2007-11-14T13:41:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sergei Organov wrote:\n\n> Just a wild idea. Doesn't it make sense to introduce perfect ultimate\n> common ancestor of the universe, probably calling it \"the NULL commit\"?\n> At first glance it seems that it can help to avoid corner cases\n> automagically.\n\nNo. Sometimes you want unrelated branches in repository ('html', 'man',\n'todo' branches in git.git), sometimes multiple roots are natural (merging\nin a project, like git-mailtools, gitweb, gitk, git-gui in git.git).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"59849","messageId":"vpqfxz8c46z.fsf@bauges.imag.fr","threadId":"10827","inReplyTo":"fhettp$rtk$1@ger.gmane.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-14T14:05:56Z","receivedAt":"2007-11-14T14:05:56Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jakub Narebski writes:\n\n> Sergei Organov wrote:\n>\n>> Just a wild idea. Doesn't it make sense to introduce perfect ultimate\n>> common ancestor of the universe, probably calling it \"the NULL commit\"?\n>> At first glance it seems that it can help to avoid corner cases\n>> automagically.\n>\n> No. Sometimes you want unrelated branches in repository ('html', 'man',\n> 'todo' branches in git.git), sometimes multiple roots are natural (merging\n> in a project, like git-mailtools, gitweb, gitk, git-gui in git.git).\n\nThere's no contradiction IMHO. At least bzr and Mercurial have the\nnotion of \"null revision\" that is a kind of virtual ancestor of the\nfirst revision of a project, and AFAICT, they supprot having unrelated\nbranches in the same repository, and merging originally unrelated\nprojects together (not sure for Mercurial, but bzr can do it).\n\nIt just depends on the definition of \"starting a project\". Either you\nsay you start the project with \"init\", in which case all projects\nstart with the same thing, or you say you start with the first\n\"commit\" in which case every project start with something different.\n\nAnyway, we can't modify existing git projects now (adding an ancestor\nto the initial revision would change each sha1 sum), so adding this\nconcept to git now would probably break all of it :-\\.\n\n-- \nMatthieu\n"},{"id":"59850","messageId":"874pfo6hkl.fsf@osv.gnss.ru","threadId":"10827","inReplyTo":"fhettp$rtk$1@ger.gmane.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-14T14:13:30Z","receivedAt":"2007-11-14T14:13:30Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Jakub Narebski writes:\n\n> Sergei Organov wrote:\n>\n>> Just a wild idea. Doesn't it make sense to introduce perfect ultimate\n>> common ancestor of the universe, probably calling it \"the NULL commit\"?\n>> At first glance it seems that it can help to avoid corner cases\n>> automagically.\n>\n> No. Sometimes you want unrelated branches in repository ('html', 'man',\n> 'todo' branches in git.git), sometimes multiple roots are natural (merging\n> in a project, like git-mailtools, gitweb, gitk, git-gui in git.git).\n\nSorry, I fail to see how does it interfere with the idea of the NULL\ncommit. What if \"unrelated\" is defined as \"the only common\nancestor is the NULL commit\"?\n\nAnyway, I'm not going do defend the idea further. I just recalled I\nheard about it somewhere, probably in Bazaar-NG, and I thought I'd\nmention it here as it appeared very natural to me.\n\n-- \nSergei.\n"},{"id":"59863","messageId":"7vfxz8hbcf.fsf@gitster.siamese.dyndns.org","threadId":"10827","inReplyTo":"87myth58r5.fsf@osv.gnss.ru","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-14T19:32:32Z","receivedAt":"2007-11-14T19:32:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergei Organov writes:\n\n> Junio C Hamano writes:\n>\n>> His second point is also a real issue. If you allowed cloning\n>> an empty repo (either bare or non-bare), then you and Bill can\n>> both clone from it, come up with an initial commit each. Bill\n>> pushes his initial commit first. Your later attempt to push\n>> will hopefully fail with \"non fast forward\", if you know better\n>> than forcing such a push, but then what? You need to fetch, and\n>> merge (or rebase) your change on top of Bill's initial commit,\n>> and at that point the history you are trying to merge does not\n>> have any common ancestor with his history.\n>\n> Just a wild idea. Doesn't it make sense to introduce perfect ultimate\n> common ancestor of the universe, probably calling it \"the NULL commit\"?\n> At first glance it seems that it can help to avoid corner cases\n> automagically.\n\nThe tools do not have problem with the multiple-root issue; we\ncan merge without common ancestor just fine. So in that area,\nwe do not need to kludge like that at the physical level (you\ncan think of root commits having \"the NULL\" as their parents).\n\nBut cloning void to start the same project by multiple people\nand pushing their initial commits as roots to start a project\nindicates the lack of developer communication (besides, it just\nfeels like a bad style, a hangover from centralized SCM\nmentality, but that is fine).\n\nIf the \"feature\" can be supported with zero cost, I do not have\na problem. If that feature does something one does not agree\nwith (be it promoting a bad workflow or whatever), one does not\nhave to use it. All one has to do is try not to recommend using\nthat feature to others.\n\nBut this time, the \"feature\" is not a zero cost thing. As\nMatthieu said in the thread, we do not let you do so right now.\nWhich means that it would involve new development, the code\nchanges would risk regressing behaviour existing users rely on,\nand we would need testing for that. These all take resources.\n\nWe already spent quite a lot of time on this thread, and at\nleast to me I feel that my time would have been better spent if\ninstead I were looking at patches on some other topics, or\nworking on cleaning up cherry-pick/revert implementation.\n"},{"id":"59869","messageId":"18235.22445.16228.535898@lisa.zopyra.com","threadId":"10827","inReplyTo":"7vfxz8hbcf.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-11-14T20:16:45Z","receivedAt":"2007-11-14T20:16:45Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, November 14, 2007 at 11:32:32 (-0800) Junio C Hamano writes:\n>Sergei Organov writes:\n>\n>> Junio C Hamano writes:\n>>\n>>> His second point is also a real issue. If you allowed cloning\n>>> an empty repo (either bare or non-bare), then you and Bill can\n>>> both clone from it, come up with an initial commit each. Bill\n>>> pushes his initial commit first. Your later attempt to push\n>>> will hopefully fail with \"non fast forward\", if you know better\n>>> than forcing such a push, but then what? You need to fetch, and\n>>> merge (or rebase) your change on top of Bill's initial commit,\n>>> and at that point the history you are trying to merge does not\n>>> have any common ancestor with his history.\n>>\n>> Just a wild idea. Doesn't it make sense to introduce perfect ultimate\n>> common ancestor of the universe, probably calling it \"the NULL commit\"?\n>> At first glance it seems that it can help to avoid corner cases\n>> automagically.\n>...\n>But cloning void to start the same project by multiple people\n>and pushing their initial commits as roots to start a project\n>indicates the lack of developer communication (besides, it just\n>feels like a bad style, a hangover from centralized SCM\n>mentality, but that is fine). ...\n\nWe have several users who have been using git for the past 9 months\nand they each find this unreasonably complicated. We realize it is\nwork, perhaps not of the highest importance, but it's also easy for\nmore experienced users to simply pooh-pooh the ideas that newer users\nhave as \"silly\" because instead of the two steps they would like, they\ncan \"just\" do the five \"easy\" steps.\n\nWell, here's what we'd like:\n\n% mkdir new_repo\n% cd new_repo\n% git --bare init\n\n[on another machine:]\n% git clone git://host/new_repo\n% cd new_repo\n% git init\n[add content]\n% git commit -a -m \"Initial stuff\"\n% git push\n\nSo, this is hard work, and other priorities intrude. Ok.\n\nInstead, we have to 1) figure out how to do this right, because it's\ndifficult to remember and not intuitive, and 2) once we have \"figured\nit out\", really figure it out, because there are a few gotchas:\n\n% mkdir new_repo\n% cd new_repo\n% git --bare init\n\n% mkdir new_repo\n% cd new_repo\n[add content]\n% git commit -a -m \"Initial stuff\"\n% git config remote.origin.url git://host/new_repo\n% git push\n[ach! fails! what's up??]\n[poke, read, poke some more, try other things..]\n[try setting the remote.origin.fetch? No, that doesn't work]\n[try setting branch.master.remote? Just edit by hand??]\n% git push master\n[fails again; read some more; think, think, think...]\n% git push origin master\n[aha! finally it works]\n\nBut now, I have a repo in which I cannot just say \"git push\" to update\nmy remote repo.\n\nSo, if we can't have clone \"do the right thing\", then it would be nice\nif we had something to allow us to do this, perhaps an argument to git\ninit:\n\n% mkdir new_repo\n% cd new_repo\n% git --bare init\n\n[on another machine:]\n% mkdir new_repo\n% cd new_repo\n% git init --mirror git://host/new_repo\n[add content]\n% git commit -a -m \"Initial stuff\"\n% git push\n\nWhere 'git init --mirror ' just sets up the config file\nproperly.\n\nSomething to think about ...\n\n\nBill\n"},{"id":"59870","messageId":"18235.22791.974033.758825@lisa.zopyra.com","threadId":"10827","inReplyTo":"18235.22445.16228.535898@lisa.zopyra.com","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-11-14T20:22:31Z","receivedAt":"2007-11-14T20:22:31Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"[I sent a few mistakes --- edited below.]\nOn Wednesday, November 14, 2007 at 14:16:45 (-0600) Bill Lear writes:\n>...\n>Well, here's what we'd like:\n>\n>% mkdir new_repo\n>% cd new_repo\n>% git --bare init\n>\n>[on another machine:]\n>% git clone git://host/new_repo\n>% cd new_repo\n>% git init\n[No git init would be needed here, obviously.]\n>[add content]\n>% git commit -a -m \"Initial stuff\"\n>% git push\n>\n>So, this is hard work, and other priorities intrude. Ok.\n>\n>Instead, we have to 1) figure out how to do this right, because it's\n>difficult to remember and not intuitive, and 2) once we have \"figured\n>it out\", really figure it out, because there are a few gotchas:\n>\n>% mkdir new_repo\n>% cd new_repo\n>% git --bare init\n>\n>% mkdir new_repo\n>% cd new_repo\n[git init is needed here...]\n>[add content]\n>% git commit -a -m \"Initial stuff\"\n>% git config remote.origin.url git://host/new_repo\n>% git push\n>[ach! fails! what's up??]\n>[poke, read, poke some more, try other things..]\n>[try setting the remote.origin.fetch? No, that doesn't work]\n>[try setting branch.master.remote? Just edit by hand??]\n>% git push master\n>[fails again; read some more; think, think, think...]\n>% git push origin master\n>[aha! finally it works]\n>...\n\nSorry for the sloppiness.\n\n\nBill\n"},{"id":"59874","messageId":"14F93E86-32FA-41AD-BB02-256A599C82E0@wincent.com","threadId":"10827","inReplyTo":"18235.22445.16228.535898@lisa.zopyra.com","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-14T20:30:46Z","receivedAt":"2007-11-14T20:30:46Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 14/11/2007, a las 21:16, Bill Lear escribió:\n\n> % mkdir new_repo\n> % cd new_repo\n> [add content]\n> % git commit -a -m \"Initial stuff\"\n> % git config remote.origin.url git://host/new_repo\n> % git push\n> [ach! fails! what's up??]\n> [poke, read, poke some more, try other things..]\n> [try setting the remote.origin.fetch? No, that doesn't work]\n> [try setting branch.master.remote? Just edit by hand??]\n> % git push master\n> [fails again; read some more; think, think, think...]\n> % git push origin master\n> [aha! finally it works]\n\n\nInstead of using git-config I think the following would have worked:\n\ngit remote add origin git.example.com:/pub/git/path_repositories/ \nrepo.git\ngit push --all\n\nI guess it is not necessarily obvious the first time, which more than \nanything makes this a documentation issue. I now can't remember how I \nlearnt this; probably by reading this list.\n\nCheers,\nWincent\n"},{"id":"59878","messageId":"Pine.LNX.4.64.0711142047170.4362@racer.site","threadId":"10827","inReplyTo":"18235.22445.16228.535898@lisa.zopyra.com","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-14T20:58:29Z","receivedAt":"2007-11-14T20:58:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Nov 2007, Bill Lear wrote:\n\n> On Wednesday, November 14, 2007 at 11:32:32 (-0800) Junio C Hamano writes:\n>\n> >But cloning void to start the same project by multiple people and \n> >pushing their initial commits as roots to start a project indicates the \n> >lack of developer communication (besides, it just feels like a bad \n> >style, a hangover from centralized SCM mentality, but that is fine). \n> >...\n> \n> We have several users who have been using git for the past 9 months and \n> they each find this unreasonably complicated. [...]\n> \n> Well, here's what we'd like:\n> \n> % mkdir new_repo\n> % cd new_repo\n> % git --bare init\n> \n> [on another machine:]\n> % git clone git://host/new_repo\n> % cd new_repo\n> % git init\n> [add content]\n> % git commit -a -m \"Initial stuff\"\n> % git push\n\nI have a better idea:\n\n[the initial import, on another machine:]\n% mkdir new_repo\n% cd new_repo\n% git init\n[add content]\n% git commit -a -m \"Initial stuff\"\n% git remote add origin git://host/repo\n% git push origin master\n\nIf you do not want to be bothered with setting up the default \n\"remote\" and \"merge\" config variables manually, it is reasonable to ask \nfor support to do that in \"git remote\".\n\nIf you really think that this workflow has anything to do with cloning an \nempty repository, I cannot help you. I mean, you did not need to clone \nthe big, empty void to do the initial commit, or did you?\n\n(I actually think that it is another example of cvs/svn damage, where you \n_need_ to clone first, or otherwise you will _never_ be able to commit \nto the repository.)\n\nBTW I am somewhat disgusted by your usage of git:// for pushing.\n\nCiao,\nDscho\n"},{"id":"59889","messageId":"18235.34578.886521.944550@lisa.zopyra.com","threadId":"10827","inReplyTo":"Pine.LNX.4.64.0711142047170.4362@racer.site","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-11-14T23:38:58Z","receivedAt":"2007-11-14T23:38:58Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, November 14, 2007 at 20:58:29 (+0000) Johannes Schindelin writes:\n>...\n>I have a better idea:\n>\n>[the initial import, on another machine:]\n>% mkdir new_repo\n>% cd new_repo\n>% git init\n>[add content]\n>% git commit -a -m \"Initial stuff\"\n>% git remote add origin git://host/repo\n>% git push origin master\n>\n>If you do not want to be bothered with setting up the default \n>\"remote\" and \"merge\" config variables manually, it is reasonable to ask \n>for support to do that in \"git remote\".\n\nUm, ok, but the above means that this repo now differs from other\nrepos, in that pushing now involves more than 'git push', i.e.,\n'git push origin master'. Is there not a way to configure it \"as if\"\nI had done a 'git clone' and thereafter could just do 'git push'?\n\nI want to do: 1) point to origin; 2) push; and not have to remember\n\"oh yeah, this is that 'special' repo and I have to tack on 'origin\nmaster' or it won't work\", or to clone it somewhere else and work\nthere.\n\n>If you really think that this workflow has anything to do with cloning an \n>empty repository, I cannot help you. I mean, you did not need to clone \n>the big, empty void to do the initial commit, or did you?\n\nI just want to point to it and treat it as if it had been cloned to\nbegin with: it is my future \"point of origin\". If it is not cloning,\nthen it is \"pointing to it as my origin\", as if it were created by the\nclone.\n\nWhat's wrong with 'git init --mirror git://host/repo'? Is it just\nanother special case that's busy work helping only a few, or does\nit belong elsewhere in your opinion?\n\n>(I actually think that it is another example of cvs/svn damage, where you \n>_need_ to clone first, or otherwise you will _never_ be able to commit \n>to the repository.)\n\nI think there is a tendency here to blame every shortcoming of git on\nsomeone else's supposedly unsanitary past rather than facing up to\ninherent problems in git itself. We have several very senior, very\ndedicated software developers who LOVE git, and who loathe CVS, but\nwho nevertheless find many vexing issues in git.\n\n>BTW I am somewhat disgusted by your usage of git:// for pushing.\n\nWhatever. We went through this before on the list and push support\nwas added to git://. We have SUCKY sysadmin support at our company\nand permissions were getting HOSED using ssh pushes. The git://\nprotocol makes everything clean on the repo side and no nasty\nsurprises with permissions and no delays begging the support team to\nclean things up.\n\n\nBill\n"},{"id":"59893","messageId":"Pine.LNX.4.64.0711150018160.4362@racer.site","threadId":"10827","inReplyTo":"18235.34578.886521.944550@lisa.zopyra.com","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-15T00:28:29Z","receivedAt":"2007-11-15T00:28:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Nov 2007, Bill Lear wrote:\n\n> On Wednesday, November 14, 2007 at 20:58:29 (+0000) Johannes Schindelin writes:\n> >...\n> >I have a better idea:\n> >\n> >[the initial import, on another machine:]\n> >% mkdir new_repo\n> >% cd new_repo\n> >% git init\n> >[add content]\n> >% git commit -a -m \"Initial stuff\"\n> >% git remote add origin git://host/repo\n> >% git push origin master\n> >\n> >If you do not want to be bothered with setting up the default \n> >\"remote\" and \"merge\" config variables manually, it is reasonable to ask \n> >for support to do that in \"git remote\".\n> \n> Um, ok, but the above means that this repo now differs from other\n> repos, in that pushing now involves more than 'git push', i.e.,\n> 'git push origin master'.\n\nNope. That is necessary only for the initial push.\n\nRemember: \"git push\" defaults to pushing to the remote \"origin\", and _all_ \nlocal branches which the remote knows about.\n\nAnd the latter is the reason why the initial push needs a special \nhandling: the local and the remote repository have no branches in common, \nbecause the remote one does not have _any_ branch yet!\n\nSo, once you pushed the initial push, you can drop the \"origin master\" \nfrom subsequent pushes!\n\n> What's wrong with 'git init --mirror git://host/repo'?\n\nIt's highly unlikely that you have the same in mind as git when you say \n\"--mirror\" in this context. Just have a look at git-push, which has \nrecently acquired that option.\n\nBesides, we really have \"clone\" for \"init + fetch\".\n\n> >(I actually think that it is another example of cvs/svn damage, where \n> >you _need_ to clone first, or otherwise you will _never_ be able to \n> >commit to the repository.)\n> \n> I think there is a tendency here to blame every shortcoming of git on \n> someone else's supposedly unsanitary past rather than facing up to \n> inherent problems in git itself.\n\nI am not blaming here. I just try to see where it comes from.\n\nIn git, all repositories are equal. Provided you can connect two of them \n(or not even that; think of bundles), you can push back and forth between \n_all_ of them.\n\nSince this is something I like about git, I had some problems finding out \nwhere this \"I have to clone from the same repository I want to push to\" \nidea comes from.\n\n> We have several very senior, very dedicated software developers who \n> LOVE git, and who loathe CVS, but who nevertheless find many vexing \n> issues in git.\n\nAnd I am thankful that you bring up the vexing issues so that we can \ndiscuss (and hopefully fix) them.\n\n> >BTW I am somewhat disgusted by your usage of git:// for pushing.\n> \n> Whatever. We went through this before on the list and push support was \n> added to git://. We have SUCKY sysadmin support at our company and \n> permissions were getting HOSED using ssh pushes. The git:// protocol \n> makes everything clean on the repo side and no nasty surprises with \n> permissions and no delays begging the support team to clean things up.\n\nHey, if it works for you, I am all the happier! (Of course, I am in a \nbetter position than you, here; I _am_ the sysadmin, and my ssh setup Just \nWorks...)\n\nCiao,\nDscho\n"},{"id":"59903","messageId":"85mytg1f6n.fsf@lola.goethe.zz","threadId":"10827","inReplyTo":"7vfxz8hbcf.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-15T01:16:16Z","receivedAt":"2007-11-15T01:16:16Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> But cloning void to start the same project by multiple people\n> and pushing their initial commits as roots to start a project\n> indicates the lack of developer communication (besides, it just\n> feels like a bad style, a hangover from centralized SCM\n> mentality, but that is fine).\n\nI do not like the approach of policy by force. It assumes that the\ndevelopers know better than the users what the users are going to do\nwith git.\n\nFor example, I use git for tracking and versioning installations and\nupdaters of complex programs. They are basically built into a directory\ntree, and this tree is checked into a bare repository in a branch\ncorresponding to a particular customer. The trees are _target_ trees\ncreated completely by something akin to make install. So every checkin\nis from scratch. The checkins for a particular customer happen in one\nbranch so that it is easy to generate a diff and from that an updater\n(the diff gets converted into a batch file removing old files and a zip\nfile unpacking new files over the old ones).\n\nThere simply is no common reference/starting point for the disparate\nbranches. I have some \"README\" in master, but that is an utterly stupid\nand unnatural starting point.\n\nOne might argue that one should use one repository per customer and just\nshare the objects (many of which are similar). But that disallows\nmaking diffs between the trees of different customers. Since the\npurpose of git here is just to track history and not do any sort of\nmerging or rebasing, there are no interesting ancestry connections\nbetween branches.\n\nAm I stupid for using git for this sort of thing? I believe not. And\nyet git developers choose to call me stupid because my work flow does\nnot lend any sense to a common ancestor commit.\n\n> But this time, the \"feature\" is not a zero cost thing. As\n> Matthieu said in the thread, we do not let you do so right now.\n> Which means that it would involve new development, the code\n> changes would risk regressing behaviour existing users rely on,\n> and we would need testing for that. These all take resources.\n\nAnd they will continue to take resources. And since the trend goes more\nand more into name-calling on those who still feel that their workflow\njustifies disparate branches without common registered ancestry, it will\nincreasingly drain the most important resources of all: goodwill and\nenthusiasm.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"59928","messageId":"20071115061941.GC10185@sigill.intra.peff.net","threadId":"10827","inReplyTo":"7vfxz8hbcf.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-15T06:19:42Z","receivedAt":"2007-11-15T06:19:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 14, 2007 at 11:32:32AM -0800, Junio C Hamano wrote:\n\n> We already spent quite a lot of time on this thread, and at\n> least to me I feel that my time would have been better spent if\n> instead I were looking at patches on some other topics, or\n> working on cleaning up cherry-pick/revert implementation.\n\nPersonally, I think cloning empty repositories should be allowed, but\nthere are many more interesting things to be working on right now.\nHowever, I think the current behavior of not printing anything is quite\nbad, so here is a productive email that didn't take too long to write.\n\n-- >8 --\ngit-clone: print an error message when trying to clone empty repo\n\nPreviously, cloning an empty repository looked like this:\n\n$ (mkdir parent && cd parent && git --bare init)\n$ git-clone parent child\nInitialized empty Git repository in /home/peff/clone/child/.git/\n$ cd child\n-bash: cd: child: No such file or directory\n$ echo 'wtf?' | mail git@vger.kernel.org\n\nNow we at least report that the clone was not successful.\n\n---\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 18003ab..e2b7a9c 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -278,7 +278,8 @@ yes)\n \t\t\t\t find objects -type f -print | sed -e 1q)\n \t\t\t# objects directory should not be empty because\n \t\t\t# we are cloning!\n-\t\t\ttest -f \"$repo/$sample_file\" || exit\n+\t\t\ttest -f \"$repo/$sample_file\" ||\n+\t\t\t\tdie \"fatal: cannot clone empty repository\"\n \t\t\tif ln \"$repo/$sample_file\" \"$GIT_DIR/objects/sample\" 2>/dev/null\n \t\t\tthen\n \t\t\t\trm -f \"$GIT_DIR/objects/sample\"\n"},{"id":"59952","messageId":"473C0661.5010307@op5.se","threadId":"10827","inReplyTo":"18235.34578.886521.944550@lisa.zopyra.com","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-15T08:42:09Z","receivedAt":"2007-11-15T08:42:09Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Bill Lear wrote:\n> \n> What's wrong with 'git init --mirror git://host/repo'?\n\nIt wouldn't match other --mirror options. You would want it to set up\nrefs/remotes namespace for you, but the other --mirror options (those\nin push/fetch) are meant to explicitly ignore refs/remotes and make\nsure branches are named exactly the same on both sides (hence --mirror).\n\nI wouldn't mind if it was given some other option that did what you\nwanted, but having --mirror mean two such very different things would\nbe bad.\n\n\"git init --remote origin=git://host/repo\", where the lhs of the equal\nsign would default to \"origin\" might be a good way to implement it.\n\nPersonally I don't have any problems with the current way of getting\nthings done, so it's not my itch.\n\n> \n>> (I actually think that it is another example of cvs/svn damage, where you \n>> _need_ to clone first, or otherwise you will _never_ be able to commit \n>> to the repository.)\n> \n> I think there is a tendency here to blame every shortcoming of git on\n> someone else's supposedly unsanitary past rather than facing up to\n> inherent problems in git itself. We have several very senior, very\n> dedicated software developers who LOVE git, and who loathe CVS, but\n> who nevertheless find many vexing issues in git.\n> \n\ngit is not perfect. It's just better than everything else. Bringing up\nthose vexing issues here is one way of making it better though, so thanks\nfor doing that. :)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"59954","messageId":"473C0875.3020805@op5.se","threadId":"10827","inReplyTo":"85mytg1f6n.fsf@lola.goethe.zz","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-15T08:51:01Z","receivedAt":"2007-11-15T08:51:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"David Kastrup wrote:\n> Junio C Hamano writes:\n> \n>> But cloning void to start the same project by multiple people\n>> and pushing their initial commits as roots to start a project\n>> indicates the lack of developer communication (besides, it just\n>> feels like a bad style, a hangover from centralized SCM\n>> mentality, but that is fine).\n> \n> I do not like the approach of policy by force. It assumes that the\n> developers know better than the users what the users are going to do\n> with git.\n> \n\nJunio just said \"but that is fine\", so afaiu he's not against allowing\nit per se. It's just that him and the other frequent contributors don't\nhave this particular problem, so if *they* fix it it will\na) Not be done with enthusiasm, and it would indeed drain enthusiasm and\n happiness from the project.\nb) Perhaps not be done the way those who want this feature would like it.\nc) Take another scarce resource (time) from other, more pressing issues\n which may or may not affect your workflow too.\n\nJunio also suggested what's likely to be needed for this to work \"properly\",\nie, an extension to the git protocol to let it transfer symref content.\n\nSince empty repositories have HEAD pointing to refs/heads/master by default,\nyou might get away with a simpler implementation.\n\n> For example, I use git for tracking and versioning installations and\n> updaters of complex programs. They are basically built into a directory\n> tree, and this tree is checked into a bare repository in a branch\n> corresponding to a particular customer. The trees are _target_ trees\n> created completely by something akin to make install. So every checkin\n> is from scratch. The checkins for a particular customer happen in one\n> branch so that it is easy to generate a diff and from that an updater\n> (the diff gets converted into a batch file removing old files and a zip\n> file unpacking new files over the old ones).\n> \n> There simply is no common reference/starting point for the disparate\n> branches. I have some \"README\" in master, but that is an utterly stupid\n> and unnatural starting point.\n> \n> One might argue that one should use one repository per customer and just\n> share the objects (many of which are similar). But that disallows\n> making diffs between the trees of different customers. Since the\n> purpose of git here is just to track history and not do any sort of\n> merging or rebasing, there are no interesting ancestry connections\n> between branches.\n> \n> Am I stupid for using git for this sort of thing? I believe not. And\n> yet git developers choose to call me stupid because my work flow does\n> not lend any sense to a common ancestor commit.\n> \n\nNot stupid, but most likely unusual. Optimizing git for your needs would\nimho be a bad idea. It's perfectly fine to use a tool for something else\nthan what it was intended for, but then you'll have to live with the\nfact that it *will* have a few shortcomings and that you'll have to work\naround them or fix them yourself.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"59977","messageId":"Pine.LNX.4.64.0711151330300.16728@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"10827","inReplyTo":"473C0875.3020805@op5.se","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-15T12:44:34Z","receivedAt":"2007-11-15T12:44:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Nov 2007, Andreas Ericsson wrote:\n\n> Since empty repositories have HEAD pointing to refs/heads/master by \n> default, you might get away with a simpler implementation.\n\nI recently had somebody asking me \"how do I rename master in an empty \nrepository?\" It is only logical to think in those terms if you want to \nstart your common development on no common basis at all (i.e. the empty \nset).\n\n> > Am I stupid for using git for this sort of thing? I believe not. \n> > And yet git developers choose to call me stupid because my work flow \n> > does not lend any sense to a common ancestor commit.\n> \n> Not stupid, but most likely unusual. Optimizing git for your needs would \n> imho be a bad idea. It's perfectly fine to use a tool for something else \n> than what it was intended for, but then you'll have to live with the \n> fact that it *will* have a few shortcomings and that you'll have to work \n> around them or fix them yourself.\n\nYes, I agree. That's what Open Source is: some take their formula one car \nto go shopping. In some cases, others laugh because that crate of beer \ntied to the front spoiler sure looks funny. In some of these cases, the \ndriver laughs back, because only this car allows her to go shopping for \ndinner in a town across the continent.\n\nSeriously again, there are sure things git was not optimised for. If \nsome complaints involving such (from git's POV) suboptimal workflows are \nretorted by saying so, it is not calling somebody \"stupid\". Sheesh.\n\nCiao,\nDscho\n"},{"id":"59980","messageId":"86pryb3b0t.fsf@lola.quinscape.zz","threadId":"10827","inReplyTo":"Pine.\u0004LNX.4.64.0711151330300.16728@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-15T13:15:30Z","receivedAt":"2007-11-15T13:15:30Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> Seriously again, there are sure things git was not optimised for.\n> If some complaints involving such (from git's POV) suboptimal\n> workflows are retorted by saying so, it is not calling somebody\n> \"stupid\". Sheesh.\n\n\"Conditioned by retarded systems\" is pretty close, and it was pretty\nmuch the wording employed. And then, when someone gets upset, he gets\n\"Sheesh\"ed off, basically calling him stupid again.\n\n\"People skills\" is not something I would associate with the git\ndeveloper list in general.\n\n-- \nDavid Kastrup\n"},{"id":"60188","messageId":"20071118002514.GA4458@sigill.intra.peff.net","threadId":"10827","inReplyTo":"7vfxz8hbcf.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-18T00:25:14Z","receivedAt":"2007-11-18T00:25:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Junio, can I get an ACK or NAK on the patch below? There doesn't seem to\nbe a patch for making cloning empty repos work on the horizon, but can\nwe at least improve the error message?\n\n-- >8 --\ngit-clone: print an error message when trying to clone empty repo\n\nPreviously, cloning an empty repository looked like this:\n\n$ (mkdir parent && cd parent && git --bare init)\n$ git-clone parent child\nInitialized empty Git repository in /home/peff/clone/child/.git/\n$ cd child\n-bash: cd: child: No such file or directory\n$ echo 'wtf?' | mail git@vger.kernel.org\n\nNow we at least report that the clone was not successful.\n\n---\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 18003ab..e2b7a9c 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -278,7 +278,8 @@ yes)\n \t\t\t\t find objects -type f -print | sed -e 1q)\n \t\t\t# objects directory should not be empty because\n \t\t\t# we are cloning!\n-\t\t\ttest -f \"$repo/$sample_file\" || exit\n+\t\t\ttest -f \"$repo/$sample_file\" ||\n+\t\t\t\tdie \"fatal: cannot clone empty repository\"\n \t\t\tif ln \"$repo/$sample_file\" \"$GIT_DIR/objects/sample\" 2>/dev/null\n \t\t\tthen\n \t\t\t\trm -f \"$GIT_DIR/objects/sample\"\n"},{"id":"60193","messageId":"7vejeoz7is.fsf@gitster.siamese.dyndns.org","threadId":"10827","inReplyTo":"20071118002514.GA4458@sigill.intra.peff.net","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-18T01:06:51Z","receivedAt":"2007-11-18T01:06:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Junio, can I get an ACK or NAK on the patch below?\n\nI do not think it would hurt. Is the \"local\" case the only\ncodepath that needs this (iow, we would not need this message if\nother transports die more loudly and/or we cannot tell if the\nfailure is wrong URL or empty remote repository)?\n"},{"id":"60199","messageId":"20071118032547.GC4560@sigill.intra.peff.net","threadId":"10827","inReplyTo":"7vejeoz7is.fsf@gitster.siamese.dyndns.org","subject":"Re: Cloning empty repositories, was Re: What is the idea for bare repositories?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-18T03:25:48Z","receivedAt":"2007-11-18T03:25:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Nov 17, 2007 at 05:06:51PM -0800, Junio C Hamano wrote:\n\n> > Junio, can I get an ACK or NAK on the patch below?\n> \n> I do not think it would hurt. Is the \"local\" case the only\n> codepath that needs this (iow, we would not need this message if\n> other transports die more loudly and/or we cannot tell if the\n> failure is wrong URL or empty remote repository)?\n\nGood question, and the answer is yes, it is the only spot that produces\nno useful output. The other errors are:\n\nvia ssh, git-daemon, or file:// (all using receive-pack) you get:\n$ git-clone localhost:foo bar\nInitialized empty Git repository in /home/peff/bar/.git/\nfatal: no matching remote head\nfetch-pack from 'localhost:foo' failed.\n\nvia http, you get:\n$ git-clone http://localhost/git/foo bar\nInitialized empty Git repository in /home/peff/bar/.git/\nCannot get remote repository information.\nPerhaps git-update-server-info needs to be run there?\n\nI didn't try rsync, though I expect it should be the same as http.\n\n-Peff\n"}]}