{"thread":{"id":"17644","subject":"receive.denyCurrentBranch","startedAt":"2009-02-08T04:29:10Z","lastAt":"2009-02-09T15:46:15Z","messageCount":15,"participants":["George Spelvin","Junio C Hamano","Johannes Schindelin","Jay Soffian","Jakub Narebski","Theodore Tso"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"103687","messageId":"20090208042910.19079.qmail@science.horizon.com","threadId":"17644","inReplyTo":null,"subject":"receive.denyCurrentBranch","fromName":"George Spelvin","fromEmail":"linux@horizon.com","sentAt":"2009-02-08T04:29:10Z","receivedAt":"2009-02-08T04:29:10Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"(Prompted by the 1.6.2-rc0 announcement.)\n\nMyself, I always thought the obvious way to handle this problem was to\ndetach the HEAD.  Is there a reson there's no \"detach\" option for this?\n"},{"id":"103692","messageId":"7vwsc11la3.fsf@gitster.siamese.dyndns.org","threadId":"17644","inReplyTo":"20090208042910.19079.qmail@science.horizon.com","subject":"Re: receive.denyCurrentBranch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-08T06:43:16Z","receivedAt":"2009-02-08T06:43:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"George Spelvin\" <linux@horizon.com> writes:\n\n> (Prompted by the 1.6.2-rc0 announcement.)\n>\n> Myself, I always thought the obvious way to handle this problem was to\n> detach the HEAD.  Is there a reson there's no \"detach\" option for this?\n\nLet's first think about why pushing into the current branch with the\ntraditional behaviour is bad.\n\nIf you are in control of the remote whose current branch was checked out\nwhen push was made, there are two cases:\n\n (1) You do not know what you are doing.  The first time you do \"git diff\n     HEAD\", or perhaps \"git status\", you suddenly see a lot of reverts,\n     sctach your head and cry for help;\n\n     If you set 'detach' option, this clueless user is not helped; he will\n     happily keep working and would make tons of commits on detached HEAD,\n     and next time he switches to another branch, will lose all of them.\n\n     In a sense, this is a lot worse than the current behaviour, because\n     you will do a lot more damage than just a single commit that has many\n     uninteniontal reverts as what currently happens---which can be sorted\n     out.\n\n (2) You know what you are doing.  You'd say:\n\n\t: detach HEAD at the commit before the push updated the branch\n\t$ git checkout @{1}  \n\t$ work work work\n        $ git commit\n\n     to detach the HEAD, finish the work you were doing in the pushed-into\n     repository and then:\n\n\t: check out the previous branch (i.e. go back)\n\t$ git checkout @{-1}\n\t: merge the last commit, i.e. the work you done on detached HEAD\n        $ git merge @{1}\n\n    If you allow 'detach' option, then you saved him from typing \"git\n    checkout @{1}\".  Not a big gain, especially if you compare this with\n    increased pain you are causing to people in category (1).\n\nThe case where the pushed-into repository is not yours was discussed\npreviously by Jeff King in the second thread below.\n\nPrevious discussions.\n\n    http://thread.gmane.org/gmane.comp.version-control.git/35770/focus=36291\n    http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100731\n"},{"id":"103717","messageId":"alpine.DEB.1.00.0902081128420.10279@pacific.mpi-cbg.de","threadId":"17644","inReplyTo":"20090208042910.19079.qmail@science.horizon.com","subject":"Re: receive.denyCurrentBranch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-08T10:30:12Z","receivedAt":"2009-02-08T10:30:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 7 Feb 2009, George Spelvin wrote:\n\n> (Prompted by the 1.6.2-rc0 announcement.)\n> \n> Myself, I always thought the obvious way to handle this problem was to\n> detach the HEAD.  Is there a reson there's no \"detach\" option for this?\n\nIt's insane, that's what it is.\n\nYou have _no_ business meddling with a remote working directory, _except_ \nby logging into that machine and working on that working directory \n_directly_.\n\nIf you do not agree, you have not thought about the implications, i.e. \nwhat problems you buy.\n\nCiao,\nDscho\n"},{"id":"103764","messageId":"76718490902080950r798ca02es4e560da35e499046@mail.gmail.com","threadId":"17644","inReplyTo":"alpine.DEB.1.00.0902081128420.10279@pacific.mpi-cbg.de","subject":"Re: receive.denyCurrentBranch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-08T17:50:36Z","receivedAt":"2009-02-08T17:50:36Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, Feb 8, 2009 at 5:30 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> It's insane, that's what it is.\n>\n> You have _no_ business meddling with a remote working directory, _except_\n> by logging into that machine and working on that working directory\n> _directly_.\n>\n> If you do not agree, you have not thought about the implications, i.e.\n> what problems you buy.\n\nJust by way of providing an additional perspective, I thought I'd illustrate\nhow Mercurial handles this situation:\n\n$ mkdir repoA\n$ cd repoA\nrepoA$ hg init\nrepoA$ echo foo > foo\nrepoA$ hg add foo\nrepoA$ hg commit -m \"added foo\"\nrepoA$ cd ..\n$ hg clone repoA repoB\nupdating working directory\n1 files updated, 0 files merged, 0 files removed, 0 files unresolved\n$ cd repoA\nrepoA$ cat >> .hg/hgrc <<EOF\n> [paths]\n> default = ../repoB\n> EOF\nrepoA$ echo bar > bar\nrepoA$ hg add bar\nrepoA$ hg commit -m \"added bar\"\nrepoA$ hg push\npushing to /Users/jay/repoB\nsearching for changes\nadding changesets\nadding manifests\nadding file changes\nadded 1 changesets with 1 changes to 1 files\nrepoA$ cd ../repoB\nrepoB$ hg parents\n0   d32c3edefcba   2009-02-08 11:18 -0500   jaysoffian\n  added foo\n\nrepoB$ hg glog\no  1[tip]   8e0a16e691f4   2009-02-08 11:19 -0500   jaysoffian\n|    added bar\n|\n@  0   d32c3edefcba   2009-02-08 11:18 -0500   jaysoffian\n     added foo\n\nrepoB$ echo baz > baz\nrepoB$ hg add baz\nrepoB$ hg commit -m \"added baz\"\ncreated new head\nrepoB$ hg parents\n2[tip]:0   8d7db8257fd0   2009-02-08 11:19 -0500   jaysoffian\n  added baz\n\nrepoB$ hg glog\n@  2[tip]:0   8d7db8257fd0   2009-02-08 11:19 -0500   jaysoffian\n|    added baz\n|\n| o  1   8e0a16e691f4   2009-02-08 11:19 -0500   jaysoffian\n|/     added bar\n|\no  0   d32c3edefcba   2009-02-08 11:18 -0500   jaysoffian\n     added foo\n\nNow let's look at what happens if I pull from B, instead of pushing from A:\n\n$ rm -rf repoA repoB\n$ mkdir repoA\n$ cd repoA\nrepoA$ hg init\nrepoA$ echo foo > foo\nrepoA$ hg add foo\nrepoA$ hg commit -m \"added foo\"\nrepoA$ cd ..\n$ hg clone repoA repoB\nupdating working directory\n1 files updated, 0 files merged, 0 files removed, 0 files unresolved\n$ cd repoA\nrepoA$ echo bar > bar\nrepoA$ hg add bar\nrepoA$ hg commit -m \"added bar\"\nrepoA$ cd ../repoB\nrepoB$ hg pull\npulling from /Users/jay/repoA\nsearching for changes\nadding changesets\nadding manifests\nadding file changes\nadded 1 changesets with 1 changes to 1 files\n(run 'hg update' to get a working copy)\ncallisto:~/repoB$ hg parents\n0   1adbe0643fb7   2009-02-08 11:22 -0500   jaysoffian\n  added foo\n\nrepoB$ hg glog\no  1[tip]   66a5c6395cfc   2009-02-08 11:22 -0500   jaysoffian\n|    added bar\n|\n@  0   1adbe0643fb7   2009-02-08 11:22 -0500   jaysoffian\n     added foo\n\nrepoB$ echo baz > baz\nrepoB$ hg add baz\nrepoB$ hg commit -m \"added baz\"\ncreated new head\nrepoB$ hg parents\n2[tip]:0   cb8f0c639bd4   2009-02-08 11:23 -0500   jaysoffian\n  added baz\n\nrepoB$ hg glog\n@  2[tip]:0   cb8f0c639bd4   2009-02-08 11:23 -0500   jaysoffian\n|    added baz\n|\n| o  1   66a5c6395cfc   2009-02-08 11:22 -0500   jaysoffian\n|/     added bar\n|\no  0   1adbe0643fb7   2009-02-08 11:22 -0500   jaysoffian\n     added foo\n\nWhat I especially like about Mercurial here is that pushing from A is\nperfectly symetrical to pulling from B.\n\nWith git, cloning sets things up to fetch into a tracking branch, but then the\npush is not symetric to the fetch. That makes sense if you're cloning from a\nbare repo, but I think leads to confusion for new users when they clone a\nnon-bare repo they wish to later push into. I dunno, I guess we'll see if the\nnew message helps any.\n\nj.\n"},{"id":"103782","messageId":"alpine.DEB.1.00.0902082149380.10279@pacific.mpi-cbg.de","threadId":"17644","inReplyTo":"76718490902080950r798ca02es4e560da35e499046@mail.gmail.com","subject":"Re: receive.denyCurrentBranch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-08T20:54:09Z","receivedAt":"2009-02-08T20:54:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 8 Feb 2009, Jay Soffian wrote:\n\n> On Sun, Feb 8, 2009 at 5:30 AM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> > It's insane, that's what it is.\n> >\n> > You have _no_ business meddling with a remote working directory, _except_\n> > by logging into that machine and working on that working directory\n> > _directly_.\n> >\n> > If you do not agree, you have not thought about the implications, i.e.\n> > what problems you buy.\n> \n> Just by way of providing an additional perspective, I thought I'd illustrate\n> how Mercurial handles this situation:\n>\n> [... lots of lines which say in a long and winding manner the same as \n>  the following...] \n>\n> What I especially like about Mercurial here is that pushing from A is \n> perfectly symetrical to pulling from B.\n\nJust to make it clear: if you have merge conflicts on the remote end, you \nwill get into trouble.\n\nI do not know how Mercurial handles this (I am sure you will send a \npage-long mail illustrating it), but in my humble opinion, there is _no_ \nway to handle this except if you have shell access to the remote \nrepository/working directory.\n\nNo matter if you suggest leaving merge conflict, a detached HEAD, or \n\"read-tree -u -m HEAD\" (i.e. trying a simple merge with the working \ndirectory): _all_ of them are unsafe.\n\nCiao,\nDscho\n"},{"id":"103787","messageId":"m3eiy8vb7t.fsf@localhost.localdomain","threadId":"17644","inReplyTo":"76718490902080950r798ca02es4e560da35e499046@mail.gmail.com","subject":"Re: receive.denyCurrentBranch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-02-08T22:03:40Z","receivedAt":"2009-02-08T22:03:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n\n> What I especially like about Mercurial here is that pushing from A is\n> perfectly symetrical to pulling from B.\n> \n> With git, cloning sets things up to fetch into a tracking branch,\n> but then the push is not symetric to the fetch. That makes sense if\n> you're cloning from a bare repo, but I think leads to confusion for\n> new users when they clone a non-bare repo they wish to later push\n> into. I dunno, I guess we'll see if the new message helps any.\n\nPush _is_ symmetric to fetch; it is not symmetric to pull, and it\ncannot be.  BTW. Mercurial's pull is equivalent to Git's fetch.\n\nThat is of course provided that you have the same refspec(s) for\npush and for fetch.  And up to the point: push needs to be via\nauthenticated channel, for obvious reasons.\n\nThe fact that default setup is not symmetric reflect the fact\nthat in most cases the situation is not symmetric: you fetch\nfrom other remote repository into separate remotes layout,\nyou push into your own public bare publishing repository set\nup in mirroring mode.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"103789","messageId":"76718490902081416n47299227wd4087bf3f3eeba45@mail.gmail.com","threadId":"17644","inReplyTo":"alpine.DEB.1.00.0902082149380.10279@pacific.mpi-cbg.de","subject":"Re: receive.denyCurrentBranch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-08T22:16:24Z","receivedAt":"2009-02-08T22:16:24Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, Feb 8, 2009 at 3:54 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> I do not know how Mercurial handles this (I am sure you will send a\n> page-long mail illustrating it)\n\nNo, I will not. Sorry for trying to help. Over and out.\n\nj.\n"},{"id":"103792","messageId":"76718490902081451xd953e84y33de64cc82c1da42@mail.gmail.com","threadId":"17644","inReplyTo":"alpine.DEB.1.00.0902082149380.10279@pacific.mpi-cbg.de","subject":"Re: receive.denyCurrentBranch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-08T22:51:16Z","receivedAt":"2009-02-08T22:51:16Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, Feb 8, 2009 at 3:54 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Just to make it clear: if you have merge conflicts on the remote end, you\n> will get into trouble.\n>\n> I do not know how Mercurial handles this (I am sure you will send a\n> page-long mail illustrating it), but in my humble opinion, there is _no_\n> way to handle this except if you have shell access to the remote\n> repository/working directory.\n\nI apologize for my prior reply. I understand you find any mention of\nMercurial offensive. But if you had paid attention, you would have\nnoticed that Mercurial did not attempt to merge. Rather, it created a\nnew branch head in the remote repository.\n\nThe equivalent in git would be for the user to do something like this:\n\nsatellite:~/repo (master)$ git push origin\n! [remote rejected] master -> master (branch is currently checked out)\nsatellite:~/repo (master)$ git push origin master:satellite-master\n * [new branch]      master -> satellite-master\nsatellite:~/repo (master)$ ssh origin\norigin$ cd repo\norigin:~/repo (master)$ git merge satellite-master\n\n> No matter if you suggest leaving merge conflict, a detached HEAD, or\n> \"read-tree -u -m HEAD\" (i.e. trying a simple merge with the working\n> directory): _all_ of them are unsafe.\n\nI'm not suggesting any of those things. I was just illustrating what\nanother DVCS does to see if there was anything that might be learned\nfrom it.\n\nClearly users are confused about pushing into a checked-out branch.\nMaybe making that impossible by default will be enough.\n\nj.\n"},{"id":"103795","messageId":"alpine.DEB.1.00.0902090038550.10279@pacific.mpi-cbg.de","threadId":"17644","inReplyTo":"76718490902081451xd953e84y33de64cc82c1da42@mail.gmail.com","subject":"Re: receive.denyCurrentBranch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-08T23:41:42Z","receivedAt":"2009-02-08T23:41:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 8 Feb 2009, Jay Soffian wrote:\n\n> If you had paid attention, you would have noticed that Mercurial did not \n> attempt to merge. Rather, it created a new branch head in the remote \n> repository.\n\nSo this is the \"detached HEAD\" idea.  Which contradicts the law of the \nleast surprise.\n\n> Clearly users are confused about pushing into a checked-out branch. \n> Maybe making that impossible by default will be enough.\n\nIt should be clear that the equivalent of a central repository is a bare \nrepository.  And hopefully Junio's strategy will make that clearer, so I \nthink this is the superior approach.\n\nCiao,\nDscho\n"},{"id":"103801","messageId":"7vtz74wfsm.fsf@gitster.siamese.dyndns.org","threadId":"17644","inReplyTo":"alpine.DEB.1.00.0902090038550.10279@pacific.mpi-cbg.de","subject":"Re: receive.denyCurrentBranch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-09T01:38:17Z","receivedAt":"2009-02-09T01:38:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Sun, 8 Feb 2009, Jay Soffian wrote:\n>\n>> If you had paid attention, you would have noticed that Mercurial did not \n>> attempt to merge. Rather, it created a new branch head in the remote \n>> repository.\n>\n> So this is the \"detached HEAD\" idea.  Which contradicts the law of the \n> least surprise.\n\nI do not think so.  It is \"adopting the symmetric mothership-satellite\nlayout, when it suits the user's workflow\".\n"},{"id":"103802","messageId":"76718490902081747s7a1ebe12yaf08665429a594c6@mail.gmail.com","threadId":"17644","inReplyTo":"alpine.DEB.1.00.0902090038550.10279@pacific.mpi-cbg.de","subject":"Re: receive.denyCurrentBranch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-09T01:47:26Z","receivedAt":"2009-02-09T01:47:26Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, Feb 8, 2009 at 6:41 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Sun, 8 Feb 2009, Jay Soffian wrote:\n>\n>> If you had paid attention, you would have noticed that Mercurial did not\n>> attempt to merge. Rather, it created a new branch head in the remote\n>> repository.\n>\n> So this is the \"detached HEAD\" idea.  Which contradicts the law of the\n> least surprise.\n\nI agree that a detached HEAD is a bad idea. The closest parallel that\nI can come up with for git would be for receive-pack to store incoming\nchanges into separate branch hierarchy, NOT for it to detach HEAD. A\ntoy-patch I played around with earlier allowed this on the non-bare\nupstream repo:\n\n[receive]\n     prefix = refs/remotes/incoming\n\nThen a push to refs/heads/master was automatically stored as\nrefs/remotes/incoming/master instead.\n\nAnd yes, I'm aware the user can use a push refspec on the sending side.\n\n> It should be clear that the equivalent of a central repository is a bare\n> repository.  And hopefully Junio's strategy will make that clearer, so I\n> think this is the superior approach.\n\nI foresee new user doing this:\n\nlaptop:~$ git clone ssh://workstation/~/repo\nlaptop:~$ cd repo\nlaptop:~/repo (master)$ echo change >> file && git commit -am change\nlaptop:~/repo (master)$ git push\n...\nerror: refusing to update checked out branch: refs/heads/master\nTo ssh://workstation/~/repo\n ! [remote rejected] master -> master (branch is currently checked out)\nerror: failed to push some refs to 'ssh://workstation/~/repo'\n\nAnd now new user is stumped.\n\nPerhaps adding something like this to the git-push man page:\n\n---8<---\n\nNon-bare Repositories\n---------------------\nWhen pushing to a non-bare upstream repository (i.e. an upstream repository\nwith a working copy), changes to the checked out branch are NOT reflected in\nthe upstream index, nor in the working copy. This creates a situation where it\nis easy to accidentally revert the changes on the next commit in the upstream\nrepository.\n\ne.g. Assume the following history exists in the upstream repository:\n\nA---B master\n\nmaster is the currently checked out branch, nothing is staged in the index and\nthe working copy is clean.\n\nA single change is made to master downstream and pushed. The upstream\nrepository is now in this state:\n\nA---B---C master\n\nHowever, the index and working copy reflect the state at commit B. Performing\na new commit in the upstream repository would do this:\n\nA---B---C---B' master\n\nB' is a new commit, but reflects the same state as B.\n\nIn order to prevent this situation, it is recommended that if you need to push\ninto a non-bare upstream repository, set receive.denyCurrentBranch = true in\nthe upstream repository (this will become the default in git-X.Y). This will\nprevent the push from occurring. Instead, you can push into an alternate\nbranch, and then merge that branch in the upstream repository. e.g.:\n\nserver$ cd ~/repo && git config receive.denyCurrentBranch true\n\nlaptop$ git push\n...\nerror: refusing to update checked out branch: refs/heads/master\nTo ssh://server/~/repo\n ! [remote rejected] master -> master (branch is currently checked out)\nerror: failed to push some refs to 'ssh://server/~/repo'\nlaptop$ git push origin master:refs/remotes/laptop/master\nlaptop$ ssh server\nserver$ cd ~/repo\nserver$ git merge laptop/master\n\nAlternatively, you can set receive.denyCurrentBranch = warn in the upstream\nrepo, but then you must remember to perform \"git reset --hard\" in the upstream\nrepo after pushing to its currently checked out branch. (But be careful, as\n\"git reset --hard\" throws away uncommitted changes.)\n\n---8<---\n\nj.\n"},{"id":"103814","messageId":"20090209050659.GA12655@mini-me.lan","threadId":"17644","inReplyTo":"76718490902081747s7a1ebe12yaf08665429a594c6@mail.gmail.com","subject":"Re: receive.denyCurrentBranch","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2009-02-09T05:06:59Z","receivedAt":"2009-02-09T05:06:59Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Feb 08, 2009 at 08:47:26PM -0500, Jay Soffian wrote:\n> I agree that a detached HEAD is a bad idea. The closest parallel that\n> I can come up with for git would be for receive-pack to store incoming\n> changes into separate branch hierarchy, NOT for it to detach HEAD. A\n> toy-patch I played around with earlier allowed this on the non-bare\n> upstream repo:\n> \n> [receive]\n>      prefix = refs/remotes/incoming\n> \n> Then a push to refs/heads/master was automatically stored as\n> refs/remotes/incoming/master instead.\n\nWhat happens when the next person pushes to the same remote repo, and\ntheir refs/heads/master push is not a fast-forward merge of the\ncurrent refs/remotes/incoming/master?\n\nDo you lose the first user's push at that point?  Or do you refuse the\npush?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"103832","messageId":"alpine.DEB.1.00.0902091204100.10279@pacific.mpi-cbg.de","threadId":"17644","inReplyTo":"20090209050659.GA12655@mini-me.lan","subject":"Re: receive.denyCurrentBranch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-09T11:06:44Z","receivedAt":"2009-02-09T11:06:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 9 Feb 2009, Theodore Tso wrote:\n\n> On Sun, Feb 08, 2009 at 08:47:26PM -0500, Jay Soffian wrote:\n> > I agree that a detached HEAD is a bad idea. The closest parallel that\n> > I can come up with for git would be for receive-pack to store incoming\n> > changes into separate branch hierarchy, NOT for it to detach HEAD. A\n> > toy-patch I played around with earlier allowed this on the non-bare\n> > upstream repo:\n> > \n> > [receive]\n> >      prefix = refs/remotes/incoming\n> > \n> > Then a push to refs/heads/master was automatically stored as\n> > refs/remotes/incoming/master instead.\n> \n> What happens when the next person pushes to the same remote repo, and\n> their refs/heads/master push is not a fast-forward merge of the\n> current refs/remotes/incoming/master?\n> \n> Do you lose the first user's push at that point?  Or do you refuse the\n> push?\n\nThis is meant for non-bare repositories, right?  Repositories that do have \nreflogs...\n\nCiao,\nDscho\n\nP.S.: There _have_ been times when I would have liked an automatic \nPUSH_HEAD that is always temporary, such as FETCH_HEAD.  I _could_ imagine \nthat this is something we could do (opt-in, of course): storing what was \nalready pushed in a PUSH_HEAD, even if the refs could not be updated.\n"},{"id":"103851","messageId":"76718490902090743j6f1bfdcdkdf9f64ca51c4a0af@mail.gmail.com","threadId":"17644","inReplyTo":"20090209050659.GA12655@mini-me.lan","subject":"Re: receive.denyCurrentBranch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-09T15:43:31Z","receivedAt":"2009-02-09T15:43:31Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 9, 2009 at 12:06 AM, Theodore Tso <tytso@mit.edu> wrote:\n> On Sun, Feb 08, 2009 at 08:47:26PM -0500, Jay Soffian wrote:\n>>\n>> [receive]\n>>      prefix = refs/remotes/incoming\n>>\n>> Then a push to refs/heads/master was automatically stored as\n>> refs/remotes/incoming/master instead.\n>\n> What happens when the next person pushes to the same remote repo, and\n> their refs/heads/master push is not a fast-forward merge of the\n> current refs/remotes/incoming/master?\n>\n> Do you lose the first user's push at that point?  Or do you refuse the\n> push?\n\nThe idea initially was to give a place to store the push head for the\nchecked-out branch, but that isn't what HEAD points to. But it seemed\nconfusing to do this for just the checked-out branch, so I was playing\nwith having all incoming pushes go into their own namespace, hence the\nprefix.\n\nAlso, the use case I have in mind here is an individual with a\nworkstation and a laptop, and the repository on the workstation and\nits clone on the laptop are both non-bare. There are not multiple\nindividuals pushing to the non-bare repo. Someone please correct me if\nI'm wrong, but it is my impression that these are the users that have\nmotivated the receive.denyCurrentBranch option (and its eventual\ndefault changing to refuse) in the first place.\n\nIn that case, the work-flow is typically:\n\nserver$ mkdir repo && cd repo && git init\nserver$ ... add, commit, add, commit ...\n  [...time passes...]\nlaptop$ git clone ssh://server/~/repo\nlaptop$ ... add, commit, add, commit ...\nlaptop$ git push\nlaptop$ ssh server\nserver$ cd repo\nserver$ git merge incoming/master\nserver$ git branch -dr incoming/master\n\nBut, to answer your question, the non-fast-forward push is rejected,\nunless the user forces it, unless receive.denyNonFastForwards prevents\nthe force.\n\nj.\n"},{"id":"103852","messageId":"76718490902090746x49e06f54sa409eacf1078ddca@mail.gmail.com","threadId":"17644","inReplyTo":"alpine.DEB.1.00.0902091204100.10279@pacific.mpi-cbg.de","subject":"Re: receive.denyCurrentBranch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-02-09T15:46:15Z","receivedAt":"2009-02-09T15:46:15Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 9, 2009 at 6:06 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> On Mon, 9 Feb 2009, Theodore Tso wrote:\n>>\n>>\n>> What happens when the next person pushes to the same remote repo, and\n>> their refs/heads/master push is not a fast-forward merge of the\n>> current refs/remotes/incoming/master?\n>>\n>> Do you lose the first user's push at that point?  Or do you refuse the\n>> push?\n>\n> This is meant for non-bare repositories, right?  Repositories that do have\n> reflogs...\n\nAbsolutely. It would be insane on a bare repository.\n\n> P.S.: There _have_ been times when I would have liked an automatic\n> PUSH_HEAD that is always temporary, such as FETCH_HEAD.  I _could_ imagine\n> that this is something we could do (opt-in, of course): storing what was\n> already pushed in a PUSH_HEAD, even if the refs could not be updated.\n\nOooh. Interesting idea.\n\nj.\n"}]}