{"thread":{"id":"13225","subject":"[RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","startedAt":"2008-04-23T08:28:36Z","lastAt":"2008-04-24T06:23:23Z","messageCount":9,"participants":["Paolo Bonzini","Johannes Schindelin","Junio C Hamano","Daniel Barkalow","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"75043","messageId":"480EF334.1090907@gnu.org","threadId":"13225","inReplyTo":null,"subject":"[RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-23T08:28:36Z","receivedAt":"2008-04-23T08:28:36Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"In the thread \"git remote update -> rejected\" Junio and Johannes came to \nthe conclusion that \"--mirror means that you do not have local \nbranches\", because \"you give control away to the other end on the ref \nnamespace\". Furthermore, it was agreed that --mirror currently makes \nsense mostly (or only?) on a bare repository.\n\n From here I gather that if you have \"git remote add --mirror\", most \nlikely the mirrored repository will be the only remote you have. There \nis in general no point in having other remotes in a bare repository. \nAnd so there is no loss of generality if this remote is the \"origin\" remote.\n\nHence, my proposal is:\n\n1) Add an option to \"git clone\", to be used with --bare, to create a \nmirror. --bare already leaves the original refs in place, without \nmoving them under refs/remotes/origin, so it makes sense to optionally \ncreate the remote.\n\nActually you don't need to add a new option. Right now, specifying \n-o/--origin together with --bare would give an error; in my proposal, if \nyou had \"--bare --origin=source\" a remote would be created in the config \nfile like this:\n\n[remote \"source\"]\n\turl = ...\n\tfetch = +refs/*:refs/*\n\n2) Modify the --mirror option to \"git remote add\", so that it creates a \nremote *acting as a mirror of this one*. The config would look like this:\n\n[remote \"mirror\"]\n url = ...\n fetch = +refs/heads/*:refs/remotes/mirror/*\n push = +refs/heads/*:refs/heads/*\n push = +refs/tags/*:refs/tags/*\n mirror\n\n\nNow, I know that this is not what was proposed in the original --mirror \nthread, and it is backwards-incompatible. On the other hand, I think it \nhas several advantages:\n\n1) it does not add special cases such as \"--mirror is only to be used in \na --bare repository\". It moves the functionality to a combination of \noptions that used to give an error.\n\n2) it provides an easy-to-use UI to create a mirror of this repository \nsomewhere. With a patch I already posted, \"git push\" would \nautomatically update this mirror.\n\n3) overall, I think it makes a lot of sense: \"git remote add\" is about \nadding one remote of many, and \"git clone\" is about setting up a single \nspecial remote. Now, you can have many remotes that are \nmirrored-from-here, while you can only have one remote that is \nmirrored-to-here. So, I believe that \"git remote add\" should add \nmirrored-from-here remotes, while \"git clone\" should be used to create a \nmirrored-to-here remote.\n\nOpinions?\n\nPaolo\n"},{"id":"75050","messageId":"alpine.DEB.1.00.0804231057470.4181@eeepc-johanness","threadId":"13225","inReplyTo":"480EF334.1090907@gnu.org","subject":"Re: [RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-23T09:59:59Z","receivedAt":"2008-04-23T09:59:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Apr 2008, Paolo Bonzini wrote:\n\n> In the thread \"git remote update -> rejected\" Junio and Johannes came to \n> the conclusion that \"--mirror means that you do not have local \n> branches\", because \"you give control away to the other end on the ref \n> namespace\". Furthermore, it was agreed that --mirror currently makes \n> sense mostly (or only?) on a bare repository.\n\nYes. But the opposite may not be true: if you plan to work on many \nworkdirs, but the same repository, you might still want to have separate \nremotes layout.\n\nIn any case, I think that this discussion is too early: clone should be \nbuiltin first, making things much simpler because of being a very thin \nlayer on top of init && remote && fetch.\n\nBut yes, there is a lot of work left on the builtin-clone to make it so.\n\nCiao,\nDscho\n"},{"id":"75071","messageId":"7vhcdstv0f.fsf@gitster.siamese.dyndns.org","threadId":"13225","inReplyTo":"480EF334.1090907@gnu.org","subject":"Re: [RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-23T16:07:28Z","receivedAt":"2008-04-23T16:07:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini writes:\n\n> In the thread \"git remote update -> rejected\" Junio and Johannes came\n> to the conclusion that \"--mirror means that you do not have local\n> branches\", because \"you give control away to the other end on the ref\n> namespace\". Furthermore, it was agreed that --mirror currently makes\n> sense mostly (or only?) on a bare repository.\n>\n> From here I gather that if you have \"git remote add --mirror\", most\n> likely the mirrored repository will be the only remote you have.\n> There is in general no point in having other remotes in a bare\n> repository. And so there is no loss of generality if this remote is\n> the \"origin\" remote.\n>\n> Hence, my proposal is:\n>\n> 1) Add an option to \"git clone\", to be used with --bare, to create a\n> mirror. --bare already leaves the original refs in place, without\n> moving them under refs/remotes/origin, so it makes sense to optionally\n> create the remote.\n\nI actually had a slightly different vision. A mid-term goal should be to\nreimplement \"clone\" that has a lot of code duplication with \"fetch\" and\n\"remote\" in terms of \"init + remote + fetch + checkout\" [*1*]. For that\nto happen, I suspect that \"remote\" needs to learn a few more tricks than\nit currently knows (e.g. \"figuring out the HEAD\").\n\nI would agree that it is useful for \"clone\" to create a bare repository in\na mode that can be used for further cloning by other repositories (perhaps\nthe former sits at the firewall boundary that it is cumbersome to cross by\nthe latter). As you described above, we already have that (iow, \"--bare\").\n\nAnd \"remote add --mirror\" would be an implementation detail to produce\nsuch a clone. It is mostly about fetching.\n\nAn option to add a back-up repository that you can maintain an exact\nmirror of your working repository would be useful, but that is different\nfrom what \"remote add --mirror\" is about.\n\n[Footnote]\n\n*1* In that sense, a more sensible order than rewriting \"clone\" in C in\nits current form would be to make necessary enhancements to the components\nin this sequence that need to implement clone, figure out how they should\nfit together and first make \"clone\" a four-liner shell script. Then\nrewriting the result in C may become more trivial.\n"},{"id":"75075","messageId":"alpine.LNX.1.00.0804231210000.19665@iabervon.org","threadId":"13225","inReplyTo":"7vhcdstv0f.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-04-23T16:56:41Z","receivedAt":"2008-04-23T16:56:41Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 23 Apr 2008, Junio C Hamano wrote:\n\n> *1* In that sense, a more sensible order than rewriting \"clone\" in C in\n> its current form would be to make necessary enhancements to the components\n> in this sequence that need to implement clone, figure out how they should\n> fit together and first make \"clone\" a four-liner shell script. Then\n> rewriting the result in C may become more trivial.\n\nclone can't be a four-liner shell script, because it has to come up with \nthe name of the working directory for a non-bare clone, which doesn't make \nsense for any other program. Currently, a local clone is special in that \nit duplicates all of the objects without checking whether the destination \nalready has them (because it can't have anything) or whether they're \nactually needed; fetch could do some similar stuff, but couldn't do quite \nthat much optimization, because it's not likely the same special case.\n\nSomething needs to get the code to figure out the remote HEAD, and it \nshouldn't be \"remote\" for clone's use, because then clone would take an \nextra connection, since \"fetch\" obviously has to connect and \"remote\" \nwould run before it and in a separate process.\n\nIt also needs to support --reference (list another repository's refs as \nyour refs, because you have that repository as an alternate but don't have \nyour own refs that use its objects), which is sort of plausible for fetch \nbut much less useful.\n\nAside from that, it's obviously got quite a few lines of option parsing to \nget the right arguments to the things it calls, as well as determining \nwhether to check out a branch (depending on what we did with the origin) \nand such.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"75100","messageId":"480F96A8.6020304@gnu.org","threadId":"13225","inReplyTo":"7vhcdstv0f.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-23T20:06:00Z","receivedAt":"2008-04-23T20:06:00Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> *1* In that sense, a more sensible order than rewriting \"clone\" in C in\n> its current form would be to make necessary enhancements to the components\n> in this sequence that need to implement clone, figure out how they should\n> fit together and first make \"clone\" a four-liner shell script. Then\n> rewriting the result in C may become more trivial.\n\nOn the other hand, a C version may have the necessary APIs available to \nsupport this kind of enhancement, but the APIs may not be there for a \nshell script.\n\nIt seems useless to have an option in \"git remote add\" just because it \nmight be necessary in a future refactoring of \"git clone\", but without a \ngood use case beside that one -- because right now \"git remote add \n--mirror\" is close to useless: anyone who needs it 99% of the time knows \nhow to hack the config, unlike people who just want a quick way to \nremotely backup of their repository.\n\nPaolo\n"},{"id":"75110","messageId":"7vtzhsqlfi.fsf@gitster.siamese.dyndns.org","threadId":"13225","inReplyTo":"480F96A8.6020304@gnu.org","subject":"Re: [RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-23T22:02:41Z","receivedAt":"2008-04-23T22:02:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini writes:\n\n> It seems useless to have an option in \"git remote add\" just because it\n> might be necessary in a future refactoring of \"git clone\", but without\n> a good use case beside that one.\n\nOoo. But I think that's the other way around. It was prepared for that\npurpose but people never followed through. Check the archive around\ncommit 3894439 (Teach \"git remote\" a mirror mode, 2007-09-02).\n\n> --mirror\" is close to useless: anyone who needs it 99% of the time\n> knows how to hack the config...\n\nEh, in that sense, \"git remote\" itself is useless, isn't it? I have to\nsay that this particular point of your argument does not give us any new\nor interesting insight to work from.\n\nAs I already said, I think \"push to backup\" option would be useful. It\njust cannot take over --mirror option, which means something different.\n"},{"id":"75113","messageId":"20080423222505.GF30057@sigill.intra.peff.net","threadId":"13225","inReplyTo":"alpine.LNX.1.00.0804231210000.19665@iabervon.org","subject":"Re: [RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-23T22:25:05Z","receivedAt":"2008-04-23T22:25:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 23, 2008 at 12:56:41PM -0400, Daniel Barkalow wrote:\n\n> Something needs to get the code to figure out the remote HEAD, and it \n> shouldn't be \"remote\" for clone's use, because then clone would take an \n> extra connection, since \"fetch\" obviously has to connect and \"remote\" \n> would run before it and in a separate process.\n\nActually, having \"fetch\" figure out the HEAD would be a nice feature,\nsince then you could track the remote's idea of HEAD as time passes.\n\nAIUI, we could get by with a single connection over git:// with a\nprotocol extension.\n\n-Peff\n"},{"id":"75114","messageId":"alpine.DEB.1.00.0804232340310.26553@eeepc-johanness","threadId":"13225","inReplyTo":"7vtzhsqlfi.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-23T22:42:01Z","receivedAt":"2008-04-23T22:42:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Apr 2008, Junio C Hamano wrote:\n\n> Paolo Bonzini writes:\n> \n> > It seems useless to have an option in \"git remote add\" just because it \n> > might be necessary in a future refactoring of \"git clone\", but without \n> > a good use case beside that one.\n> \n> Ooo. But I think that's the other way around.\n\nI think it is very much the other way round. \"git remote add\" is meant \nfor adding _additional_ remotes. \"git clone\" just _happens_ to install an \n\"origin\" remote.\n\nI even have a case where I used \"--mirror\" _twice_ in the same, _non_-bare \nrepository. It has merit, you know?\n\nCiao,\nDscho\n"},{"id":"75139","messageId":"4810275B.70404@gnu.org","threadId":"13225","inReplyTo":"7vtzhsqlfi.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Moving \"git remote add --mirror blah\" functionality to \"git clone --bare --origin=blah\"","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-24T06:23:23Z","receivedAt":"2008-04-24T06:23:23Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"> Ooo. But I think that's the other way around. It was prepared for that\n> purpose but people never followed through. Check the archive around\n> commit 3894439 (Teach \"git remote\" a mirror mode, 2007-09-02).\n\nWell, the thread is not very explicative. Neither is the commit log \nmessage. There is no info as to *why* it is useful.\n\nAfter finding no particularly good info in the commit, and seeing that \nthe functionality is unused within git's shell script porcelain, I wrote \nmy RFC on the intuition that it is a failed experiment. (The rest of \nthis message is also assuming this possibly wrong intuition).\n\n>> --mirror\" is close to useless: anyone who needs it 99% of the time\n>> knows how to hack the config...\n> \n> Eh, in that sense, \"git remote\" itself is useless, isn't it?\n\nHm, bad sentence on my side. My point was that my proposed improvements \nto clone:\n\n git clone --bare -o origin foo.git\n\nsatisfy 99% of the usecase; you usually know beforehand if you're \ncloning for local development or for mirrors. Anyone who *still* needs \n--mirror after that (i.e. needs two mirror-mode remotes, or needs it on \nnon-bare repositories), 99% of the time knows how to hack the config. \nActually in the latter case (non-bare repos) he might have to hack the \nconfig soon, if Dscho's patch to forbid this is polished and goes in.\n\nIn the end, this piece of functionality is almost unused (surely unused \nwithin git's shell porcelain, if not in the wild) and is dubiously \nplaced for two reasons:\n\n1) If the point of git remote is to shield from the config, what the \nuser will learn is that \"git remote\" is about \"git branch -r\" (maybe \nhe'll also learn \"refs/remotes/something\"). Now instead you have an \noption that goes under \"git remote\" just because it creates remote.* \nconfiguration options. Indeed, \"git remote add --mirror -f\" will create \n*local* branches, so that \"git branch -r\" does not show them.\n\n2) Similarly, \"--mirror\" suggests that the remote will go hand in hand \nwith \"git push\" (that has the \"--mirror\" option, and this started my \nconfusion) rather than \"git fetch\"/\"git pull\". Indeed, even after my \npatch[1] to add some DWIM functionality for mirrors to \"git push\", the \nuser will need to hack the config file manually to activate the DWIM.\n\nInstead, my proposed meaning of \"git remote add --mirror\" would fix both \ndiscrepancies...\n\nPaolo\n\n[1] http://marc.info/?l=git&m=120877130932254&w=2\n"}]}