{"thread":{"id":"12816","subject":"Working copy revision and push pain","startedAt":"2008-03-23T12:39:13Z","lastAt":"2008-03-31T02:09:21Z","messageCount":32,"participants":["Jonathan Watt","Johannes Schindelin","Elijah Newren","Johan Herland","Junio C Hamano","Jan Hudec","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72738","messageId":"47E64F71.3020204@jwatt.org","threadId":"12816","inReplyTo":null,"subject":"Working copy revision and push pain","fromName":"Jonathan Watt","fromEmail":"jwatt@jwatt.org","sentAt":"2008-03-23T12:39:13Z","receivedAt":"2008-03-23T12:39:13Z","isPatch":false,"sender":{"key":"jwatt@jwatt.org","avatar":null},"body":"Hi,\n\nThere seems to be a problem with git-push when the working copy of the directory\nbeing pushed to came from the magic revision HEAD, but not when the working copy\ncame from some other revision.\n\nSay I've got a repository called a:\n\n mkdir a\n cd a\n git-init\n echo \"line 1\" > file\n git-add file\n git-commit -m \"commit 1\" file\n echo \"line 2\" >> file\n git-commit -m \"commit 2\" file\n echo \"line 3\" >> file\n git-commit -m \"commit 3\" file\n\nNow let's say there's a clone of repository a called b, and b has HEAD checked\nout. If I make changes in a and push them to b, there's a problem:\n\n git-clone . ../b\n echo \"line 4\" >> file\n git-commit -m \"commit 4\" file\n git-push ../b\n cd ../b\n git-log file # says the working copy came from commit 4, but...\n cat file # only lists up to line 3 :-/\n\nIf on the other hand I have a clone of repository a called c that has a non-HEAD\nrevision checked out, there's no problem:\n\n git-clone ../a ../c\n cd ../c\n git-checkout HEAD^\n cd ../a\n echo \"line 5\" >> file\n git-commit -m \"commit 5\" file\n git-push ../c\n cd ../c\n git-log file # says the working copy came from commit 3, and...\n cat file # only lists up to line 3. great!\n\nI don't know anything about the implementation of git, but could this mean that\nwhen the working copy comes from HEAD git tracks it as coming from the revision\n\"HEAD\" instead of the underlying revision's sha1? If so, this seems like an\nunnecessary gotcha/pain point. Couldn't git be changed to always track the sha1\nof the revision it really came from? That would seem like the correct thing to\ndo, and it would be nice to avoid unnecessarily breaking working copies.\n\nRegards,\nJonathan\n"},{"id":"72740","messageId":"alpine.LSU.1.00.0803231401340.4353@racer.site","threadId":"12816","inReplyTo":"47E64F71.3020204@jwatt.org","subject":"Re: Working copy revision and push pain","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T13:02:48Z","receivedAt":"2008-03-23T13:02:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, Jonathan Watt wrote:\n\n> There seems to be a problem with git-push when the working copy of the \n> directory being pushed to came from the magic revision HEAD, but not \n> when the working copy came from some other revision.\n\nhttp://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73\n\nSidenote: I am constantly amazed how people have no problem accepting that \na CVS-Server has no working directory, but all of a sudden think that a \nGit-server should have one, and auto-update it.\n\nCiao,\nDscho\n"},{"id":"72743","messageId":"47E658D3.1060104@jwatt.org","threadId":"12816","inReplyTo":"alpine.LSU.1.00.0803231401340.4353@racer.site","subject":"Re: Working copy revision and push pain","fromName":"Jonathan Watt","fromEmail":"jwatt@jwatt.org","sentAt":"2008-03-23T13:19:15Z","receivedAt":"2008-03-23T13:19:15Z","isPatch":false,"sender":{"key":"jwatt@jwatt.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 23 Mar 2008, Jonathan Watt wrote:\n> \n>> There seems to be a problem with git-push when the working copy of the \n>> directory being pushed to came from the magic revision HEAD, but not \n>> when the working copy came from some other revision.\n> \n> http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73\n> \n> Sidenote: I am constantly amazed how people have no problem accepting that \n> a CVS-Server has no working directory, but all of a sudden think that a \n> Git-server should have one, and auto-update it.\n\nHi Dscho. I think you've misread my email. (Or not read it. ;-)) I do not expect\ngit-push to update the working copy of the repository being pushed to. In fact\nmy complaint would be more that it *does* appear to modify the working copy\n(well, not so much modify the working copy as get confused about which revision\nthe working copy came from) when the working copy came from HEAD.\n\nJonathan\n"},{"id":"72747","messageId":"51419b2c0803230645l5b07bbf5h9cbf9b6f47373efa@mail.gmail.com","threadId":"12816","inReplyTo":"47E658D3.1060104@jwatt.org","subject":"Re: Working copy revision and push pain","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-03-23T13:45:07Z","receivedAt":"2008-03-23T13:45:07Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Mar 23, 2008 at 7:19 AM, Jonathan Watt wrote:\n> Johannes Schindelin wrote:\n> > Hi,\n> >\n> > On Sun, 23 Mar 2008, Jonathan Watt wrote:\n> >\n> >> There seems to be a problem with git-push when the working copy of the\n> >> directory being pushed to came from the magic revision HEAD, but not\n> >> when the working copy came from some other revision.\n> >\n> > http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73\n> >\n> > Sidenote: I am constantly amazed how people have no problem accepting that\n> > a CVS-Server has no working directory, but all of a sudden think that a\n> > Git-server should have one, and auto-update it.\n>\n> Hi Dscho. I think you've misread my email. (Or not read it. ;-)) I do not expect\n> git-push to update the working copy of the repository being pushed to. In fact\n> my complaint would be more that it *does* appear to modify the working copy\n> (well, not so much modify the working copy as get confused about which revision\n> the working copy came from) when the working copy came from HEAD.\n\nAh, I hadn't thought of it that way before. I think you are\nsuggesting that pushing to the active branch of a repository with an\nassociated working copy should cause the HEAD to become detached. Is\nthat right? That's an interesting new twist to this old problem that\nI personally haven't seen before (though I am kind of new and have\nonly had a little time to dig up archives about this problem). Hmm...\n"},{"id":"72749","messageId":"47E6612A.5020408@jwatt.org","threadId":"12816","inReplyTo":"51419b2c0803230645l5b07bbf5h9cbf9b6f47373efa@mail.gmail.com","subject":"Re: Working copy revision and push pain","fromName":"Jonathan Watt","fromEmail":"jwatt@jwatt.org","sentAt":"2008-03-23T13:54:50Z","receivedAt":"2008-03-23T13:54:50Z","isPatch":false,"sender":{"key":"jwatt@jwatt.org","avatar":null},"body":"Elijah Newren wrote:\n> On Sun, Mar 23, 2008 at 7:19 AM, Jonathan Watt wrote:\n>> Johannes Schindelin wrote:\n>> > Hi,\n>> >\n>> > On Sun, 23 Mar 2008, Jonathan Watt wrote:\n>> >\n>> >> There seems to be a problem with git-push when the working copy of the\n>> >> directory being pushed to came from the magic revision HEAD, but not\n>> >> when the working copy came from some other revision.\n>> >\n>> > http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73\n>> >\n>> > Sidenote: I am constantly amazed how people have no problem accepting that\n>> > a CVS-Server has no working directory, but all of a sudden think that a\n>> > Git-server should have one, and auto-update it.\n>>\n>> Hi Dscho. I think you've misread my email. (Or not read it. ;-)) I do not expect\n>> git-push to update the working copy of the repository being pushed to. In fact\n>> my complaint would be more that it *does* appear to modify the working copy\n>> (well, not so much modify the working copy as get confused about which revision\n>> the working copy came from) when the working copy came from HEAD.\n> \n> Ah, I hadn't thought of it that way before. I think you are\n> suggesting that pushing to the active branch of a repository with an\n> associated working copy should cause the HEAD to become detached. Is\n> that right?\n\nTo be honest, I'm not sure what you mean by \"HEAD to become detached\". If you\nmean that the git-push should, if necessary, stop associating the working copy\nwith HEAD if it's going to change HEAD, then absolutely. It wasn't the same\nsolution as I was thinking of (stop associating the working copy with HEAD and\ninstead associate it with the sha1 HEAD currently points to), but I guess it's\nthe same result. :-)\n\nJonathan\n"},{"id":"72753","messageId":"51419b2c0803230706w5ff88fc7oc7e8e34ab8afa1fd@mail.gmail.com","threadId":"12816","inReplyTo":"47E6612A.5020408@jwatt.org","subject":"Re: Working copy revision and push pain","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-03-23T14:06:57Z","receivedAt":"2008-03-23T14:06:57Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Mar 23, 2008 at 7:54 AM, Jonathan Watt wrote:\n> Elijah Newren wrote:\n> > On Sun, Mar 23, 2008 at 7:19 AM, Jonathan Watt wrote:\n> >> Johannes Schindelin wrote:\n> >> > Hi,\n> >> >\n> >> > On Sun, 23 Mar 2008, Jonathan Watt wrote:\n> >> >\n> >> >> There seems to be a problem with git-push when the working copy of the\n> >> >> directory being pushed to came from the magic revision HEAD, but not\n> >> >> when the working copy came from some other revision.\n> >> >\n> >> > http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73\n> >> >\n> >> > Sidenote: I am constantly amazed how people have no problem accepting that\n> >> > a CVS-Server has no working directory, but all of a sudden think that a\n> >> > Git-server should have one, and auto-update it.\n> >>\n> >> Hi Dscho. I think you've misread my email. (Or not read it. ;-)) I do not expect\n> >> git-push to update the working copy of the repository being pushed to. In fact\n> >> my complaint would be more that it *does* appear to modify the working copy\n> >> (well, not so much modify the working copy as get confused about which revision\n> >> the working copy came from) when the working copy came from HEAD.\n> >\n> > Ah, I hadn't thought of it that way before. I think you are\n> > suggesting that pushing to the active branch of a repository with an\n> > associated working copy should cause the HEAD to become detached. Is\n> > that right?\n>\n> To be honest, I'm not sure what you mean by \"HEAD to become detached\". If you\n> mean that the git-push should, if necessary, stop associating the working copy\n> with HEAD if it's going to change HEAD, then absolutely. It wasn't the same\n> solution as I was thinking of (stop associating the working copy with HEAD and\n> instead associate it with the sha1 HEAD currently points to), but I guess it's\n> the same result. :-)\n>\n> Jonathan\n\nIn git, HEAD always refers to the currently active branch...if there\nis one. (Also note that each branch tracks its most recent commit.)\nIf there is no currently active branch because you checked out a tag\nor some arbitrary commit, then HEAD is said to be detached, and HEAD\nwill track the particular commit you checked out. The end result is\nthat HEAD is always the most recent commit to which your working copy\nis relative to. See also\nhttp://www.kernel.org/pub/software/scm/git/docs/glossary.html\n\nSo, it sounds like we're both saying that in your case, you'd like the\nHEAD become detached and track the sha1 that it previously pointed to\nbefore your push rather than continuing to track the updated branch.\n"},{"id":"72756","messageId":"alpine.LSU.1.00.0803231508320.4353@racer.site","threadId":"12816","inReplyTo":"47E658D3.1060104@jwatt.org","subject":"Re: Working copy revision and push pain","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T14:11:12Z","receivedAt":"2008-03-23T14:11:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, Jonathan Watt wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Sun, 23 Mar 2008, Jonathan Watt wrote:\n> > \n> >> There seems to be a problem with git-push when the working copy of \n> >> the directory being pushed to came from the magic revision HEAD, but \n> >> not when the working copy came from some other revision.\n> > \n> > http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73\n> > \n> > Sidenote: I am constantly amazed how people have no problem accepting \n> > that a CVS-Server has no working directory, but all of a sudden think \n> > that a Git-server should have one, and auto-update it.\n> \n> I think you've misread my email. (Or not read it. ;-))\n\nWell, I did. Thank you very much.\n\n> I do not expect git-push to update the working copy of the repository \n> being pushed to. In fact my complaint would be more that it *does* \n> appear to modify the working copy (well, not so much modify the working \n> copy as get confused about which revision the working copy came from) \n> when the working copy came from HEAD.\n\nYou changed the current branch via push. HEAD is the tip of the current \nbranch. What else should happen?\n\nYour notion that the working tree has somehow a magic state that is not \ndependent on the current branch is somewhat strange to me.\n\nCiao,\nDscho\n"},{"id":"72759","messageId":"alpine.LSU.1.00.0803231519380.4353@racer.site","threadId":"12816","inReplyTo":"51419b2c0803230706w5ff88fc7oc7e8e34ab8afa1fd@mail.gmail.com","subject":"Re: Working copy revision and push pain","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T14:22:29Z","receivedAt":"2008-03-23T14:22:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, Elijah Newren wrote:\n\n> If there is no currently active branch because you checked out a tag\n> or some arbitrary commit, then HEAD is said to be detached, and HEAD\n> will track the particular commit you checked out.\n\nI'd say that \"track\" is the wrong verb here.\n\n> The end result is that HEAD is always the most recent commit to which \n> your working copy is relative to. See also \n> http://www.kernel.org/pub/software/scm/git/docs/glossary.html\n> \n> So, it sounds like we're both saying that in your case, you'd like the\n> HEAD become detached and track the sha1 that it previously pointed to\n> before your push rather than continuing to track the updated branch.\n\nIf you ever propose to detach the HEAD in a remote repository when \nsomebody pushed into the referenced branch, I am totally opposed to that.\n\nYou can play your own games with the update and post-update hooks as much \nas you want, but please leave official Git alone. Thankyouverymuch.\n\nCiao,\nDscho\n"},{"id":"72760","messageId":"47E668E1.80804@jwatt.org","threadId":"12816","inReplyTo":"51419b2c0803230706w5ff88fc7oc7e8e34ab8afa1fd@mail.gmail.com","subject":"Re: Working copy revision and push pain","fromName":"Jonathan Watt","fromEmail":"jwatt@jwatt.org","sentAt":"2008-03-23T14:27:45Z","receivedAt":"2008-03-23T14:27:45Z","isPatch":false,"sender":{"key":"jwatt@jwatt.org","avatar":null},"body":"Elijah Newren wrote:\n> On Sun, Mar 23, 2008 at 7:54 AM, Jonathan Watt wrote:\n>> Elijah Newren wrote:\n>> > On Sun, Mar 23, 2008 at 7:19 AM, Jonathan Watt wrote:\n>> >> Hi Dscho. I think you've misread my email. (Or not read it. ;-)) I do not expect\n>> >> git-push to update the working copy of the repository being pushed to. In fact\n>> >> my complaint would be more that it *does* appear to modify the working copy\n>> >> (well, not so much modify the working copy as get confused about which revision\n>> >> the working copy came from) when the working copy came from HEAD.\n>> >\n>> > Ah, I hadn't thought of it that way before. I think you are\n>> > suggesting that pushing to the active branch of a repository with an\n>> > associated working copy should cause the HEAD to become detached. Is\n>> > that right?\n>>\n>> To be honest, I'm not sure what you mean by \"HEAD to become detached\". If you\n>> mean that the git-push should, if necessary, stop associating the working copy\n>> with HEAD if it's going to change HEAD, then absolutely. It wasn't the same\n>> solution as I was thinking of (stop associating the working copy with HEAD and\n>> instead associate it with the sha1 HEAD currently points to), but I guess it's\n>> the same result. :-)\n> \n> In git, HEAD always refers to the currently active branch...if there\n> is one. (Also note that each branch tracks its most recent commit.)\n> If there is no currently active branch because you checked out a tag\n> or some arbitrary commit, then HEAD is said to be detached, and HEAD\n> will track the particular commit you checked out. The end result is\n> that HEAD is always the most recent commit to which your working copy\n> is relative to. See also\n> http://www.kernel.org/pub/software/scm/git/docs/glossary.html\n\nI see. Thanks.\n\n> So, it sounds like we're both saying that in your case, you'd like the\n> HEAD become detached and track the sha1 that it previously pointed to\n> before your push rather than continuing to track the updated branch.\n\nYes, indeed. From my novice perspective it seems like that's absolutely what\nshould happen, since that's where the working copy came from. Certainly I see no\nreason for git-push to leave the working copy/revision relationship in a bad state.\n\nJonathan\n"},{"id":"72763","messageId":"alpine.LSU.1.00.0803231534050.4353@racer.site","threadId":"12816","inReplyTo":"47E668E1.80804@jwatt.org","subject":"Re: Working copy revision and push pain","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T14:34:54Z","receivedAt":"2008-03-23T14:34:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, Jonathan Watt wrote:\n\n> Elijah Newren wrote:\n>\n> > So, it sounds like we're both saying that in your case, you'd like the \n> > HEAD become detached and track the sha1 that it previously pointed to \n> > before your push rather than continuing to track the updated branch.\n> \n> Yes, indeed. From my novice perspective it seems like that's absolutely \n> what should happen, since that's where the working copy came from. \n> Certainly I see no reason for git-push to leave the working \n> copy/revision relationship in a bad state.\n\nThis is a horrible idea.\n\nIf you want to push into non-bare repositories, then please, please, \nplease read the tutorials on that subject.\n\nThanks,\nDscho\n"},{"id":"72764","messageId":"47E66ACA.5050806@jwatt.org","threadId":"12816","inReplyTo":"alpine.LSU.1.00.0803231508320.4353@racer.site","subject":"Re: Working copy revision and push pain","fromName":"Jonathan Watt","fromEmail":"jwatt@jwatt.org","sentAt":"2008-03-23T14:35:54Z","receivedAt":"2008-03-23T14:35:54Z","isPatch":false,"sender":{"key":"jwatt@jwatt.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n>\n> On Sun, 23 Mar 2008, Jonathan Watt wrote:\n>\n>> Johannes Schindelin wrote:\n>>\n>>> On Sun, 23 Mar 2008, Jonathan Watt wrote:\n>>>\n>>>> There seems to be a problem with git-push when the working copy of\n>>>> the directory being pushed to came from the magic revision HEAD, but\n>>>> not when the working copy came from some other revision.\n>>> http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73\n>>>\n>>> Sidenote: I am constantly amazed how people have no problem accepting\n>>> that a CVS-Server has no working directory, but all of a sudden think\n>>> that a Git-server should have one, and auto-update it.\n>> I think you've misread my email. (Or not read it. ;-))\n>\n> Well, I did. Thank you very much.\n\nThen my apologies. It just seems that you answered a different question.\n\n>> I do not expect git-push to update the working copy of the repository\n>> being pushed to. In fact my complaint would be more that it *does*\n>> appear to modify the working copy (well, not so much modify the working\n>> copy as get confused about which revision the working copy came from)\n>> when the working copy came from HEAD.\n>\n> You changed the current branch via push. HEAD is the tip of the current\n> branch. What else should happen?\n\nI would expect it to do that, *and* note that the working copy didn't come from\nwhat is the new head of HEAD.\n\n> Your notion that the working tree has somehow a magic state that is not\n> dependent on the current branch is somewhat strange to me.\n\nI don't believe that's a notion that I have. I simply have a notion that git\nshould know which revision the working copy was checked out from, and not get\nconfused and think it came from a different revision. ;-)\n\nJonathan\n"},{"id":"72766","messageId":"47E66DAA.4080807@jwatt.org","threadId":"12816","inReplyTo":"alpine.LSU.1.00.0803231519380.4353@racer.site","subject":"Re: Working copy revision and push pain","fromName":"Jonathan Watt","fromEmail":"jwatt@jwatt.org","sentAt":"2008-03-23T14:48:10Z","receivedAt":"2008-03-23T14:48:10Z","isPatch":false,"sender":{"key":"jwatt@jwatt.org","avatar":null},"body":"Johannes Schindelin wrote:\n>> The end result is that HEAD is always the most recent commit to which \n>> your working copy is relative to. See also \n>> http://www.kernel.org/pub/software/scm/git/docs/glossary.html\n>>\n>> So, it sounds like we're both saying that in your case, you'd like the\n>> HEAD become detached and track the sha1 that it previously pointed to\n>> before your push rather than continuing to track the updated branch.\n> \n> If you ever propose to detach the HEAD in a remote repository when \n> somebody pushed into the referenced branch, I am totally opposed to that.\n\nThe alternative is to leave the working copy in a totally broken state. I'm not\nsure why that would be preferable.\n\n> You can play your own games with the update and post-update hooks as much \n> as you want, but please leave official Git alone. Thankyouverymuch.\n\nMy hope here is for a reduction in the pain/time taken out from real work in the\nOSS developer world while people are moving to DSCMs - particularly for those\nthat have to learn/move between both Mercurial and git. Requiring people to be\naware of this gotcha and to use solutions like hooks seems to raise barriers\nrather than eliminate them.\n\nCloning and working with multiple repositories locally is a particularly\nMercurial workflow. I see this issue as a barrier to those who've cut their DSCM\nteeth on Mercurial and are trying to use git. Would detaching HEAD really be a\nproblem in git workflows?\n\nJonathan\n"},{"id":"72767","messageId":"alpine.LSU.1.00.0803231555380.4353@racer.site","threadId":"12816","inReplyTo":"47E66DAA.4080807@jwatt.org","subject":"Re: Working copy revision and push pain","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T14:56:56Z","receivedAt":"2008-03-23T14:56:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, Jonathan Watt wrote:\n\n> Would detaching HEAD really be a problem in git workflows?\n\nIf recovering is painful? Yes.\n\nIf it is not what you want? Yes.\n\nJust to give you a small clue what other people would like: \nhttp://utsl.gen.nz/git/post-update\n\nBTW that was in the link I sent you earlier.\n\nCiao,\nDscho\n"},{"id":"72769","messageId":"47E6765D.2020103@jwatt.org","threadId":"12816","inReplyTo":"alpine.LSU.1.00.0803231555380.4353@racer.site","subject":"Re: Working copy revision and push pain","fromName":"Jonathan Watt","fromEmail":"jwatt@jwatt.org","sentAt":"2008-03-23T15:25:17Z","receivedAt":"2008-03-23T15:25:17Z","isPatch":false,"sender":{"key":"jwatt@jwatt.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 23 Mar 2008, Jonathan Watt wrote:\n> \n>> Would detaching HEAD really be a problem in git workflows?\n> \n> If recovering is painful? Yes.\n> \n> If it is not what you want? Yes.\n\nIf you push to the current branch of a non-bare repository, then as things\nstand, whatever was pushed to the current branch will be reverted on the next\ncommit(!). Push hasn't just pushed changesets to the repository, it's\nessentially screwed up the working copy. I personally can't see how this\nbehavior is useful or in any way \"right\", or why you'd want it that way. On the\nother hand detaching HEAD makes sure that all push has done is push changesets,\nand you've essentially created a branch. To me that seems like the only correct\nthing to do. (It also happens to be the way Mercurial behaves.)\n\nI'd venture that if you're pushing into a non-bare repository then you know the\nstate of the working copy, and you know if you're going to cause pain. (And it's\nprobably local.) If it's a shared repository, why is there a working copy? If\nit's someone else's repository, the two of you probably know what you're doing.\nThese two seem like relative edge cases though, and even then, detaching HEAD\nseems like the right think to me.\n\n> Just to give you a small clue what other people would like: \n> http://utsl.gen.nz/git/post-update\n> \n> BTW that was in the link I sent you earlier.\n\nAs I said, I don't want to update the files in the working copy. Seems like a\ndifferent issue to me.\n\nJonathan\n"},{"id":"72774","messageId":"alpine.LSU.1.00.0803231658460.4353@racer.site","threadId":"12816","inReplyTo":"47E6765D.2020103@jwatt.org","subject":"Re: Working copy revision and push pain","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T16:00:12Z","receivedAt":"2008-03-23T16:00:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, Jonathan Watt wrote:\n\n> Johannes Schindelin wrote:\n> \n> > Just to give you a small clue what other people would like: \n> > http://utsl.gen.nz/git/post-update\n> > \n> > BTW that was in the link I sent you earlier.\n> \n> As I said, I don't want to update the files in the working copy. Seems \n> like a different issue to me.\n\nI understood that. *yawns*\n\nBut I tried to tell you (unsuccessfully, it seems) that this is not \ndesirable to all users, and therefore it would be a horrible, horrible \nidea to force the behaviour on other people you seemed to try to force on \nother people.\n\n'nuff said,\nDscho\n"},{"id":"72775","messageId":"200803231720.44320.johan@herland.net","threadId":"12816","inReplyTo":"alpine.LSU.1.00.0803231534050.4353@racer.site","subject":"Re: Working copy revision and push pain","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-03-23T16:20:44Z","receivedAt":"2008-03-23T16:20:44Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 23 March 2008, Johannes Schindelin wrote:\n> On Sun, 23 Mar 2008, Jonathan Watt wrote:\n> > Elijah Newren wrote:\n> If you want to push into non-bare repositories, then please, please, \n> please read the tutorials on that subject.\n\nI have personally no problem with the current default behaviour of push (in the few cases I push into non-bare repos, I've set up the proper hooks to do what I want), but I frequently get questions from colleagues about why Git behaves like this.\n\nI'm starting to think it's worth changing the default behaviour of push as follows:\n\nUpon receiving a push into a non-bare repository, if the working copy is on the same branch as is being pushed, then refuse the push with a helpful message describing why the push was refused, and how to resolve this issue (i.e. referring to the tutorials you mention).\n\nThis would:\n- Not clobber the working copy\n- Tell newbies what happened and why\n- Hopefully make this issue pop up less frequently\n- Not affect you if you only push into bare repos\n- Not affect you if you take care to never push into a checked-out branch\n\nOf course, you should be able to set a config option to get the old behaviour, and from there you can write hooks to either update the working copy, or detach HEAD, or whatever you please.\n\n\nIs this acceptable to people?\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"72781","messageId":"47E6923E.1050904@jwatt.org","threadId":"12816","inReplyTo":"200803231720.44320.johan@herland.net","subject":"Re: Working copy revision and push pain","fromName":"Jonathan Watt","fromEmail":"jwatt@jwatt.org","sentAt":"2008-03-23T17:24:14Z","receivedAt":"2008-03-23T17:24:14Z","isPatch":false,"sender":{"key":"jwatt@jwatt.org","avatar":null},"body":"Johan Herland wrote:\n> I'm starting to think it's worth changing the default behaviour of push as follows:\n> \n> Upon receiving a push into a non-bare repository, if the working copy is on the same branch as is being pushed, then refuse the push with a helpful message describing why the push was refused, and how to resolve this issue (i.e. referring to the tutorials you mention).\n> \n> This would:\n> - Not clobber the working copy\n> - Tell newbies what happened and why\n> - Hopefully make this issue pop up less frequently\n> - Not affect you if you only push into bare repos\n> - Not affect you if you take care to never push into a checked-out branch\n\nThe detach-HEAD idea does all these things, but rather:\n\n- There's no need to tell newbies anything\n- It don't just reduce the frequency of the problem, it eliminates it\n\n:-) Also,\n\n- You eliminate the problem of git thinking the working copy came from a\n revision it didn't come from, and thus eliminate the \"any commit will\n now overwrite the push\" problem\n- You can still write hooks to update the working copy if you like\n- It's completely intuitive to anyone coming from Mercurial (and it's these\n people who are going to be doing the pushing into non-bare repositories,\n because that's the workflow they're familiar with)\n\nIt might also be a good idea to print a warning about the working copy needing\nto be updated or else committing changes will create a branch. That seems\nobvious, and if you're pushing into a checked out branch, you probably know that\nthough.\n\n> Of course, you should be able to set a config option to get the old behaviour, and from there you can write hooks to either update the working copy, or detach HEAD, or whatever you please.\n> \n> Is this acceptable to people?\n\n>From my perspective it makes things more complicated rather than simpler I'm afraid.\n\nJohannes is apparently fed up of trying to explain to me why people want their\nworking copy associated with the wrong revision so that their commits will\noverwrite the pull. ;-) If anyone else cares to give it ago I'd appreciate it,\nsince I still don't see the utility.\n\nJonathan\nHoping Johannes has a sense of humour...\n"},{"id":"72787","messageId":"7vd4pl713g.fsf@gitster.siamese.dyndns.org","threadId":"12816","inReplyTo":"47E6923E.1050904@jwatt.org","subject":"Re: Working copy revision and push pain","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-23T18:21:39Z","receivedAt":"2008-03-23T18:21:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Watt writes:\n\n> Johan Herland wrote:\n>> I'm starting to think it's worth changing the default behaviour of push as follows:\n>> \n>> Upon receiving a push into a non-bare repository, if the working copy is on the same branch as is being pushed, then refuse the push with a helpful message describing why the push was refused, and how to resolve this issue (i.e. referring to the tutorials you mention).\n>> \n>> This would:\n>> - Not clobber the working copy\n>> - Tell newbies what happened and why\n>> - Hopefully make this issue pop up less frequently\n>> - Not affect you if you only push into bare repos\n>> - Not affect you if you take care to never push into a checked-out branch\n>\n> The detach-HEAD idea does all these things, but rather:\n>\n> - There's no need to tell newbies anything\n> - It don't just reduce the frequency of the problem, it eliminates it\n>\n> :-) Also,\n>\n> - You eliminate the problem of git thinking the working copy came from a\n> revision it didn't come from, and thus eliminate the \"any commit will\n> now overwrite the push\" problem\n> - You can still write hooks to update the working copy if you like\n> - It's completely intuitive to anyone coming from Mercurial (and it's these\n> people who are going to be doing the pushing into non-bare repositories,\n> because that's the workflow they're familiar with)\n\nI am obviously sympathetic to people who are in the detox program from\nMercurial poisoning ;-), but seriously, I have to wonder if the detached\nHEAD is the other way around from what merc does?\n\nMy understanding is if you push into a non-bare tree in merc, they make\nthe branch head into \"unmerged\" state, and as far as the work tree is\nconcerned you are still on the previous commit, and you merge \"the other\ncommit\" that was pushed into from sideways to update the branch tip with\npushed-into commit.\n\nIn git, if you detach HEAD when you push into a checked-out 'master', your\nwork tree won't be associated with 'master' anymore, and to merge the\npushed-into state into the history of 'master', you would need:\n\n\t# push into 'master' from elsewhere, which by your magic detaches\n # the HEAD in the pushed-into repository.\n\telsewhere$ git push $non_bare_repo master\n\n\t# merge pushed-into change into old 'master' where your work tree\n # started from by merging master into detached HEAD. Somehow you\n # need to know you were on master to be able to do this. Also\n # because you magically detached HEAD, anything else you do after\n # such a push from sideways in this repository are not protected\n # by reflog for 'master' but only by reflog for 'HEAD'.\n\there$ git merge master\n\n\t# update the master with the result of the merge\n\there$ git push . HEAD:master\n\n # check out master again to get back to your original state.\n here$ git checkout master\n\nThe second point bothers me quite a lot, as you are assuming that the\nuser at the repository that was pushed into does _not_ know what is going\non, and may keep working on a detached HEAD _without knowing_ what is\ngoing on.\n\nThere is an alternative, though.\n\nGit does not use merc style \"a single branch can have unmerged multiple\nheads\" paradigm, but it can be implemented more explicitly (look for\n\"mothership satellite\" in the FAQ you were referred to earlier).\n\nPeople in the Mercurial detox program may want to use the pattern of\npushing into acceptance branch and then merging from it when it is\nconvenient, like this:\n\n\t# push from sideways go to 'remotes/origin/master', and never to\n # 'master'. Your 'master' that was checked out is not molested\n # by this push.\n\telsewhere$ git push $non_bare_repo master:refs/remotes/origin/master\n\n\t# you can keep working on what you were doing without getting\n\t# molested by the above push.\n\there$ hack, hack, commit, commit, all still on 'master'\n\n # when you are done with the work you were doing in the pushed-into\n # tree, and notice somebody pushed into your acceptance branch,\n # you can _choose to_ merge it in.\n\there$ git merge remotes/origin/master\n"},{"id":"72788","messageId":"alpine.LSU.1.00.0803231922370.4353@racer.site","threadId":"12816","inReplyTo":"47E6923E.1050904@jwatt.org","subject":"Re: Working copy revision and push pain","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T18:23:05Z","receivedAt":"2008-03-23T18:23:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, Jonathan Watt wrote:\n\n> Hoping Johannes has a sense of humour...\n\nI do. However, I have to admit that I hate being ignored. But then, I \ncan always return the favour.\n\nCiao,\nDscho\n"},{"id":"72805","messageId":"7vhcex4485.fsf@gitster.siamese.dyndns.org","threadId":"12816","inReplyTo":"7vd4pl713g.fsf@gitster.siamese.dyndns.org","subject":"Re: Working copy revision and push pain","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-23T19:42:18Z","receivedAt":"2008-03-23T19:42:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jonathan Watt writes:\n>\n> My understanding is if you push into a non-bare tree in merc, they make\n> the branch head into \"unmerged\" state, and as far as the work tree is\n> concerned you are still on the previous commit, and you merge \"the other\n> commit\" that was pushed into from sideways to update the branch tip with\n> pushed-into commit.\n>\n> In git, if you detach HEAD when you push into a checked-out 'master', your\n> work tree won't be associated with 'master' anymore, and to merge the\n> pushed-into state into the history of 'master', you would need:\n> ...\n> The second point bothers me quite a lot, as you are assuming that the\n> user at the repository that was pushed into does _not_ know what is going\n> on, and may keep working on a detached HEAD _without knowing_ what is\n> going on.\n\nLet's back up a bit and try again.\n\nI was trying to say what Mercurial presents at the UI level may be much\nnicer with respect to pushing into a checked out repository. Their notion\nof 'head' (and 'branch' in general) is quite different from ours in that\ntheir branch can have more than one 'head's that the user can choose to\nmerge into its 'tip', and 'push' does not update the 'tip'. It instead\nadds a new (unmerged) 'head' or fast-forwards an existing 'head', and the\nuser can choose to merge them into 'tip' when convenient (please correct\nme here, since I am talking from my reading their documentation and I may\nhave misread it).\n\nIn git, a branch is just a ref and points at a single commit, and push and\nfetch updates a single ref. There is no direct notion of \"these other\nrefs are related to this branch ref and you may want to merge them\" at the\nlow level plumbing layer, so if you push to update a ref, git does what it\nis told to do. The branch ref is directly updated, and won't get split to\nbe merged back later like Mercurial does.\n\nMy objection to the \"always detach HEAD automatically\" is because that\nsolution, while it may solve the issue of work tree and HEAD getting\ninconsistent silently behind user's back, would introduce more confusion.\n\n - The repository loses where we were (so we would add a hack to record\n which branch you were on), and operations after that silent detaching\n will _not_ advance your local branch anymore, because the push took\n over the branch 'tip'. If you switch to some other branch, you lose.\n\n - The final merge happens in the wrong direction. The other commit is\n already called the official 'tip' of the branch because push took over\n the branch 'tip', and after merging it into your stale HEAD, you have\n to update 'master' with the merge made on the detached HEAD.\n\n - It's your repository and the commit you were on when this push from\n sideways happened should _stay_ as the official 'tip' of the branch,\n until you tell git so. In that sense, pushing into a non-bare\n repository's refs/heads/ hierarchy directly is conceptually wrong,\n whether the branch in question is currently checked out or not.\n\nAlthough we do not have their split branch heads, we do have a similar\nconcept by the name of \"branch tracking\". Your 'master' is marked as\nbeing related to 'remotes/origin/master' by \"git clone\" and by \"git\ncheckout -b foo remotes/origin/foo\", and recent \"git checkout\" to switch\nto such a branch will report how diverged you are from the other party.\n\nThe mothership-satellite configuration described in FAQ is about using\nthis facility, because \"git push\" into a non-bare repository is exactly a\n\"git fetch\" run in the reverse direction (i.e. fetching to pushed-into\nrepository from pushed-from repository).\n"},{"id":"72807","messageId":"51419b2c0803231248h6b161fa7qa120fd18e60e274@mail.gmail.com","threadId":"12816","inReplyTo":"alpine.LSU.1.00.0803231519380.4353@racer.site","subject":"Re: Working copy revision and push pain","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-03-23T19:48:23Z","receivedAt":"2008-03-23T19:48:23Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Sun, Mar 23, 2008 at 8:22 AM, Johannes Schindelin\n wrote:\n> On Sun, 23 Mar 2008, Elijah Newren wrote:\n>\n> > If there is no currently active branch because you checked out a tag\n> > or some arbitrary commit, then HEAD is said to be detached, and HEAD\n> > will track the particular commit you checked out.\n>\n> I'd say that \"track\" is the wrong verb here.\n\nGood point.\n\n> > The end result is that HEAD is always the most recent commit to which\n> > your working copy is relative to. See also\n> > http://www.kernel.org/pub/software/scm/git/docs/glossary.html\n> >\n> > So, it sounds like we're both saying that in your case, you'd like the\n> > HEAD become detached and track the sha1 that it previously pointed to\n> > before your push rather than continuing to track the updated branch.\n>\n> If you ever propose to detach the HEAD in a remote repository when\n> somebody pushed into the referenced branch, I am totally opposed to that.\n>\n> You can play your own games with the update and post-update hooks as much\n> as you want, but please leave official Git alone. Thankyouverymuch.\n\nObviously such a change in isolation would merely shift to a new kind\nof gotcha for users; I was thinking that I'd be able to figure out an\naccompanying change that would make things work nicely (or that\nsomeone else on the list might think of something)...but no such luck.\n Further, I think Junio's latest post describes why I likely couldn't\ncome up with anything else and the idea is just plain bad.\n\nElijah\n"},{"id":"72906","messageId":"alpine.LSU.1.00.0803241621210.4353@racer.site","threadId":"12816","inReplyTo":"200803231720.44320.johan@herland.net","subject":"Re: Working copy revision and push pain","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-24T15:22:28Z","receivedAt":"2008-03-24T15:22:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, Johan Herland wrote:\n\n> I'm starting to think it's worth changing the default behaviour of push \n> as follows:\n> \n> Upon receiving a push into a non-bare repository, if the working copy is \n> on the same branch as is being pushed, then refuse the push with a \n> helpful message describing why the push was refused, and how to resolve \n> this issue (i.e. referring to the tutorials you mention).\n> \n> This would:\n> - Not clobber the working copy\n> - Tell newbies what happened and why\n> - Hopefully make this issue pop up less frequently\n> - Not affect you if you only push into bare repos\n> - Not affect you if you take care to never push into a checked-out \n> branch\n> \n> Of course, you should be able to set a config option to get the old \n> behaviour, and from there you can write hooks to either update the \n> working copy, or detach HEAD, or whatever you please.\n\nI think I sent out a sensible patch, which does not change the behaviour \nin existing repositories. This should be safer (read: nicer) for \nGit old-timers.\n\nCiao,\nDscho\n"},{"id":"72921","messageId":"200803241900.38816.johan@herland.net","threadId":"12816","inReplyTo":"alpine.LSU.1.00.0803241621210.4353@racer.site","subject":"Re: Working copy revision and push pain","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-03-24T18:00:38Z","receivedAt":"2008-03-24T18:00:38Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 24 March 2008, Johannes Schindelin wrote:\n> On Sun, 23 Mar 2008, Johan Herland wrote:\n> > I'm starting to think it's worth changing the default behaviour of push \n> > as follows:\n> > \n> > Upon receiving a push into a non-bare repository, if the working copy is \n> > on the same branch as is being pushed, then refuse the push with a \n> > helpful message describing why the push was refused, and how to resolve \n> > this issue (i.e. referring to the tutorials you mention).\n> > \n> > This would:\n> > - Not clobber the working copy\n> > - Tell newbies what happened and why\n> > - Hopefully make this issue pop up less frequently\n> > - Not affect you if you only push into bare repos\n> > - Not affect you if you take care to never push into a checked-out \n> > branch\n> > \n> > Of course, you should be able to set a config option to get the old \n> > behaviour, and from there you can write hooks to either update the \n> > working copy, or detach HEAD, or whatever you please.\n> \n> I think I sent out a sensible patch, which does not change the behaviour \n> in existing repositories. This should be safer (read: nicer) for \n> Git old-timers.\n\nYes, I'm following the discussion between you and Junio with great interest. Will post if I have anything worthwhile to contribute. So far you both make a lot of sense.\n\nThanks a lot for the patch.\n\n\nHave fun! :)\n\n...Johan\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"73063","messageId":"20080325192552.GC4857@efreet.light.src","threadId":"12816","inReplyTo":"alpine.LSU.1.00.0803231658460.4353@racer.site","subject":"Auto detaching head options (Re: Working copy revision and push pain)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-03-25T19:25:52Z","receivedAt":"2008-03-25T19:25:52Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Mar 23, 2008 at 17:00:12 +0100, Johannes Schindelin wrote:\n> On Sun, 23 Mar 2008, Jonathan Watt wrote:\n> > As I said, I don't want to update the files in the working copy. Seems \n> > like a different issue to me.\n> \n> I understood that. *yawns*\n> \n> But I tried to tell you (unsuccessfully, it seems) that this is not \n> desirable to all users, and therefore it would be a horrible, horrible \n> idea to force the behaviour on other people you seemed to try to force on \n> other people.\n\nThe proponents of this (and I also) think, that meaning of HEAD is, or rather\nshould be, \"the revision your work tree is derived from\". If you think it\nshould be defined otherwise, can you please say how, so the merits of the\ndefinitions can be discussed?\n\nNote, that that definition implies that HEAD makes no sense for bare\nrepository. I think HEAD indeed does not make sense there, but you may of\ncourse provide different definition where it does.\n\nAlso I believe that it would be very useful to have a ref defined \"the\nrevision your work tree is derived from\", be it HEAD or not. It would:\n - make the behaviour of push to non-bare repository defined.\n - make additional work trees for a repository (created by\n contrib/workdir/git-new-workdir) safe (the mechanizm could than be an\n option for submodules).\n\nI see two ways to add something to keep track of work tree base version:\n\n1. Make HEAD a special kind of ref, that would contain *both* the symbolic\n name *and* sha1. It would behave as symbolic as long as the sha1 values\n match and as detached when they don't.\n\n This should actually be relatively small code change, because it would be\n confined to update-ref, symbolic-ref and revparse. It would however be\n quite significant change to the repository format.\n\n2. Create a new special ref BASE? (WORKTREE?), with the right semantics.\n\n The code change would be a bit more invasive here, as more commands would\n be affected (though I hope the commands share internal code so it would\n only be one checkout and one commit path). It would be smaller change to\n the repository format. It would, however, more stick out, because to find\n out which branch you will commit to would require looking at both HEAD and\n BASE.\n\n It would really be similar to the revision number in index proposal,\n except less invasive and I actually believe there is a case (some form of\n checkout or reset), where we want to read-tree, but not change this ref.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"73069","messageId":"alpine.LSU.1.00.0803252056400.10660@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"12816","inReplyTo":"20080325192552.GC4857@efreet.light.src","subject":"Re: Auto detaching head options (Re: Working copy revision and push pain)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-25T19:58:40Z","receivedAt":"2008-03-25T19:58:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 25 Mar 2008, Jan Hudec wrote:\n\n> The proponents of this (and I also) think, that meaning of HEAD is, or \n> rather should be, \"the revision your work tree is derived from\".\n\nBy far the most operation I do with HEAD is to _advance_ it. So for me, \nHEAD must be a pointer to the ref which is to be advanced.\n\nI don't care about detaching the HEAD when pushing into the current \nbranch, which you are not supposed to do anyway. Really. I could not \ncare less about that.\n\nYou can do it -- I already pointed out that you can do that with hooks -- \nbut please do not bother me with it.\n\nHth,\nDscho\n"},{"id":"73082","messageId":"20080325232424.GB5273@coredump.intra.peff.net","threadId":"12816","inReplyTo":"20080325192552.GC4857@efreet.light.src","subject":"Re: Auto detaching head options (Re: Working copy revision and push pain)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-25T23:24:24Z","receivedAt":"2008-03-25T23:24:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 25, 2008 at 08:25:52PM +0100, Jan Hudec wrote:\n\n> The proponents of this (and I also) think, that meaning of HEAD is, or rather\n> should be, \"the revision your work tree is derived from\". If you think it\n> should be defined otherwise, can you please say how, so the merits of the\n> definitions can be discussed?\n\nI agree with Johannes. It has traditionally been considered \"the ref\nthat will be advanced by new commits\". And that is why I think detaching\nthe HEAD is just trading one problem for another: your push invisibly\nmucks with state that the non-bare repository user relies on. When they\ncommit on a detached HEAD, their commits suddenly start going \"nowhere\"\ninstead of to the branch they thought.\n\nFWIW, I also initially thought this was only a \"HEAD\" problem, but I\nthink Junio's recent argument makes a lot of sense: the problem is not\none of working tree and HEAD sync, nor even of detached versus ref HEAD.\nThe problem is that somebody is using the non-bare repository to do\nstuff (why else would it be non-bare), and you are changing the state\nbehind their back.\n\n> Note, that that definition implies that HEAD makes no sense for bare\n> repository. I think HEAD indeed does not make sense there, but you may of\n> course provide different definition where it does.\n\nI think HEAD can be more generally considered the context of the\n\"current\" branch. It is the default branch for cloning from bare\nrepositories, and it is the default branch for most operations (logging,\nstarting new branches, etc). So it really is a bit overloaded in that\nsense.\n\n> Also I believe that it would be very useful to have a ref defined \"the\n> revision your work tree is derived from\", be it HEAD or not. It would:\n\nIsn't this essentially the 'base' index extension that Junio did a\nwhile back? It was eventually reverted (or perhaps never merged, I don't\nrecall). You should be able to find discussion in the list archives.\n\nBut maybe you are referencing it here:\n\n> It would really be similar to the revision number in index proposal,\n> except less invasive and I actually believe there is a case (some form of\n> checkout or reset), where we want to read-tree, but not change this ref.\n\nI don't recall the reasons the base extension was not accepted, but I\nthink it would make sense to frame your argument as \"this is like X;\npeople didn't like X for reason Y, but my proposal fixes this by...\"\n\n-Peff\n"},{"id":"73152","messageId":"7v3aqde2wn.fsf@gitster.siamese.dyndns.org","threadId":"12816","inReplyTo":"20080325232424.GB5273@coredump.intra.peff.net","subject":"Re: Auto detaching head options (Re: Working copy revision and push pain)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-26T18:49:44Z","receivedAt":"2008-03-26T18:49:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> FWIW, I also initially thought this was only a \"HEAD\" problem, but I\n> think Junio's recent argument makes a lot of sense: the problem is not\n> one of working tree and HEAD sync, nor even of detached versus ref HEAD.\n> The problem is that somebody is using the non-bare repository to do\n> stuff (why else would it be non-bare), and you are changing the state\n> behind their back.\n\nFor people who are overwhelmed by the volume of the list traffic, the\nrelevant thread is:\n\n http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062\n\n> Isn't this essentially the 'base' index extension that Junio did a\n> while back? It was eventually reverted (or perhaps never merged, I don't\n> recall).\n\nIt was in 'next' for a while but was reverted before it hit 'master':\n\n http://thread.gmane.org/gmane.comp.version-control.git/44360/focus=44508\n\n> But maybe you are referencing it here:\n>\n>> It would really be similar to the revision number in index proposal,\n>> except less invasive and I actually believe there is a case (some form of\n>> checkout or reset), where we want to read-tree, but not change this ref.\n>\n> I don't recall the reasons the base extension was not accepted, but I\n> think it would make sense to frame your argument as \"this is like X;\n> people didn't like X for reason Y, but my proposal fixes this by...\"\n\nBut if you take the position \"work tree belongs to the repository owner\nand nobody has any business pushing into it sideways; push into acceptance\nbranch and let the work tree owner merge it when able\", the history of the\nfailed index base experiment becomes irrelevant.\n"},{"id":"73304","messageId":"20080329082757.GA4920@efreet.light.src","threadId":"12816","inReplyTo":"7v3aqde2wn.fsf@gitster.siamese.dyndns.org","subject":"Auto detaching head options (update) (Re: Working copy revision and push pain)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-03-29T08:27:57Z","receivedAt":"2008-03-29T08:27:57Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"Hello All,\n\nSince the original proposal is not quoted here, I should repeat it:\nOn Tue, Mar 25, Jan Hudec wrote:\n> Also I believe that it would be very useful to have a ref defined \"the\n> revision your work tree is derived from\", be it HEAD or not. It would:\n> - make the behaviour of push to non-bare repository defined.\n> - make additional work trees for a repository (created by\n> contrib/workdir/git-new-workdir) safe (the mechanizm could than be an\n> option for submodules).\n\nFirst of all, I should apologise for proposing to introduce something that\nalready exists. It's been resting in the reflog all the time.\n\nExcluding push to non-bare repository and extra work trees, the local\nbranches are only ever updated through the HEAD. And as long as they are\nupdated with update-ref, it writes the value to the reflog, so HEAD^{0}\nshould always equal HEAD.\n\nTherefore the option to prevent users shooting themselves in the foot when\nusing multiple worktrees for the same repository (the more useful case) or\npushing to a non-bare repo (which is usually just shooting oneselves in the\nfeet because of lack of knowledge) would be to introduce an option to commit\nto verify, that rev-parse HEAD and rev-parse HEAD^{0} give the same revision.\n\nThat would have only one casuality -- currently to create a new parentless\ncommit in non-new repository, one has to modify the HEAD manually. But that\njust needs a command-line override to disable the check for cases when one\nknows what he's doing.\n\nOn Wed, Mar 26, 2008 at 11:49:44 -0700, Junio C Hamano wrote:\n> Jeff King writes:\n> > FWIW, I also initially thought this was only a \"HEAD\" problem, but I\n> > think Junio's recent argument makes a lot of sense: the problem is not\n> > one of working tree and HEAD sync, nor even of detached versus ref HEAD.\n> > The problem is that somebody is using the non-bare repository to do\n> > stuff (why else would it be non-bare), and you are changing the state\n> > behind their back.\n> \n> For people who are overwhelmed by the volume of the list traffic, the\n> relevant thread is:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062\n\nThanks for the pointer.\n\nThere are actually two use-cases for this. One is this pushing to non-bare\nrepo, which is indeed just shooting oneself in the foot out of lack of\nknowledge most of the time. Though it would still be nice to ask user \"do you\nreally want to shoot yourself in the foot?\" if we can find out.\n\nBut the other usecase is using additional work trees\n(contrib/workdir/git-new-workdir), which is rather useful for many people.\nThere it again does not make sense to commit to the same branch from two\nwork-trees, but it may easily happen by accident. Being able to check and\nprevent such accidents would improve support for extra work-trees a lot,\nmaybe even to a point it could be made official.\n\n> > Isn't this essentially the 'base' index extension that Junio did a\n> > while back? It was eventually reverted (or perhaps never merged, I don't\n> > recall).\n> \n> It was in 'next' for a while but was reverted before it hit 'master':\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/44360/focus=44508\n\nAgain, thanks for the pointer.\n\n> > But maybe you are referencing it here:\n> >\n> >> It would really be similar to the revision number in index proposal,\n> >> except less invasive and I actually believe there is a case (some form of\n> >> checkout or reset), where we want to read-tree, but not change this ref.\n> >\n> > I don't recall the reasons the base extension was not accepted, but I\n> > think it would make sense to frame your argument as \"this is like X;\n> > people didn't like X for reason Y, but my proposal fixes this by...\"\n> \n> But if you take the position \"work tree belongs to the repository owner\n> and nobody has any business pushing into it sideways; push into acceptance\n> branch and let the work tree owner merge it when able\", the history of the\n> failed index base experiment becomes irrelevant.\n\nOk. This proposal is indeed similar to the base-in-index one, but has some\nsignificant differences. See below.\n\nBesides whith the update above, I no longer propose to keep any new\ninformation -- just to add a safety-check.\n\nOn 2007-04-15 19:56:55 GMT, Junio C Hamano wrote:\n> [...]\n> This is primarily because updating the branch tip is not tied\n> closely to writing out a commit, and writing out a commit is not\n> tied closely to writing out a tree (to be contained in that\n> commit) out of the index.\n> [...]\n\nThis is a big difference between the base-in-index and\nbase-somewhere-separately. The reflog is indeed tied to updating of the\nbranch tip, which is what we need here. It also does not add any new logic to\nthe low-level plumbing (read-tree, write-tree), that the base-in-index\nproposal did.\n\nFor the BASE ref proposal, it would be equally tied to update of the branch\ntip, except that all porcelain that does it would have to be changed, while\nthe reflog it already updates.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"73307","messageId":"20080329084743.GA19200@coredump.intra.peff.net","threadId":"12816","inReplyTo":"20080329082757.GA4920@efreet.light.src","subject":"Re: Auto detaching head options (update) (Re: Working copy revision and push pain)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-29T08:47:43Z","receivedAt":"2008-03-29T08:47:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 29, 2008 at 09:27:57AM +0100, Jan Hudec wrote:\n\n> Excluding push to non-bare repository and extra work trees, the local\n> branches are only ever updated through the HEAD. And as long as they are\n> updated with update-ref, it writes the value to the reflog, so HEAD^{0}\n> should always equal HEAD.\n\nI assume by HEAD^{0} you mean HEAD@{0}? The first is for peeling tags,\nwhile the latter is \"the latest reflog entry.\"\n\nThere are a few other ways I can think of to manipulate branches besides\nthrough HEAD:\n\n - git branch -f existing new_ref (though I'm not sure if this works if\n the branch is HEAD)\n\n - git update-ref refs/heads/branch_that_is_HEAD_but_we_call_it_by_name\n\nHowever, in both cases the HEAD ref is being munged behind the user's\nback to some degree, and it can result in a situation where the index\ndoesn't match HEAD anymore. So in both cases, I think the safety check\nyou propose would actually be a benefit.\n\nBut I'm not sure if there aren't some \"innocent\" uses of the second form\nin people's scripts. For example, a script that operates on HEAD but\nresolves it internally to \"refs/heads/master\" and begins using that (and\ntakes care itself to keep the index in sync with the new value written\ninto the ref).\n\n> There are actually two use-cases for this. One is this pushing to non-bare\n> repo, which is indeed just shooting oneself in the foot out of lack of\n> [...]\n> But the other usecase is using additional work trees\n\nI like the fact that it deals with both these cases, and I think it can\ncover even more. It is a general safety valve for \"somebody changed this\nref while you weren't looking.\"\n\n> Besides whith the update above, I no longer propose to keep any new\n> information -- just to add a safety-check.\n\nAnd I like that, too. But I am a little worried that the information\nwill not be sufficient. You are asking for a consistency guarantee of\nHEAD and HEAD@{0} that comes from using current porcelain. But there are\nmany uses of plumbing that would violate that consistency guarantee. And\nsome of those are exactly what you're trying to catch and warn about.\nBut I suspect there are some false positives (either in people's\nplumbing-oriented workflows, in other scripts outside of core git, or\neven in core git itself (I didn't carefully audit how each script\nworks)). And maybe it is OK to warn and force a \"-f\" there, or cause\nthose scripts to be updated.\n\nBy all of these \"maybes\" what I am saying is \"I think this is a\npromising approach but I am not entirely convinced it won't run into\nimplementation problems.\" And of course producing a patch is a good\nfirst step in figuring it out. :)\n\n-Peff\n"},{"id":"73393","messageId":"7vy77zslor.fsf@gitster.siamese.dyndns.org","threadId":"12816","inReplyTo":"20080329084743.GA19200@coredump.intra.peff.net","subject":"Re: Auto detaching head options (update) (Re: Working copy revision and push pain)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-31T01:53:56Z","receivedAt":"2008-03-31T01:53:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sat, Mar 29, 2008 at 09:27:57AM +0100, Jan Hudec wrote:\n>\n> I like the fact that it deals with both these cases, and I think it can\n> cover even more. It is a general safety valve for \"somebody changed this\n> ref while you weren't looking.\"\n>\n>> Besides whith the update above, I no longer propose to keep any new\n>> information -- just to add a safety-check.\n>\n> And I like that, too. But I am a little worried that the information\n> will not be sufficient. You are asking for a consistency guarantee of\n> HEAD and HEAD@{0} that comes from using current porcelain.\n\nWhile I too find the proposal attractive as a concept, I am sorry to say\nthat it would not work even with the current set of Porcelain (fwiw, when\nthe index-base extension was done, the approach based on HEAD reflog would\nnot have worked either). This is because 605fac8 (update HEAD reflog when\nbranch pointed to by HEAD is directly modified, 2007-03-21) made gremlin\nupdates to the current branch tip to also update the reflog of HEAD.\n\nIf we revert that commit, we may be able to.\n"},{"id":"73394","messageId":"20080331015937.GA32645@coredump.intra.peff.net","threadId":"12816","inReplyTo":"7vy77zslor.fsf@gitster.siamese.dyndns.org","subject":"Re: Auto detaching head options (update) (Re: Working copy revision and push pain)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-31T01:59:37Z","receivedAt":"2008-03-31T01:59:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Mar 30, 2008 at 06:53:56PM -0700, Junio C Hamano wrote:\n\n> While I too find the proposal attractive as a concept, I am sorry to say\n> that it would not work even with the current set of Porcelain (fwiw, when\n> the index-base extension was done, the approach based on HEAD reflog would\n> not have worked either). This is because 605fac8 (update HEAD reflog when\n> branch pointed to by HEAD is directly modified, 2007-03-21) made gremlin\n> updates to the current branch tip to also update the reflog of HEAD.\n> \n> If we revert that commit, we may be able to.\n\nEww. I didn't know we were doing that. In fact, that was one of the\ncases I mentioned as \"this would cause the reflog to get out of sync,\nbut that is a good thing because it would trigger your safety valve.\"\nBut obviously I was wrong about how we behave now.\n\nWhy is 605fac8 beneficial? What common workflow is updating the HEAD\nbranch through its actual name? If it is manipulating the index and\nworktree at the same time, then it should be using the name HEAD. If it\nisn't, then shouldn't the HEAD and index get out of sync (exactly the\nthing Jan's proposal is meant to protect against)?\n\n-Peff\n"},{"id":"73396","messageId":"20080331020920.GA412@coredump.intra.peff.net","threadId":"12816","inReplyTo":"20080331015937.GA32645@coredump.intra.peff.net","subject":"Re: Auto detaching head options (update) (Re: Working copy revision and push pain)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-31T02:09:21Z","receivedAt":"2008-03-31T02:09:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Mar 30, 2008 at 09:59:37PM -0400, Jeff King wrote:\n\n> Why is 605fac8 beneficial? What common workflow is updating the HEAD\n> branch through its actual name? If it is manipulating the index and\n\nApparently my reading skills are not what they used to be. In the\ncomment from 605fac8, it specifically mentions pushing directly into a\nbranch that is the same as HEAD. But that is one of the cases that we\nJan is trying to improve, so I don't see a problem with reverting in\nfavor of his proposal.\n\n-Peff\n"}]}