{"thread":{"id":"11055","subject":"To push into a non-bare repository, or not to push into it...","startedAt":"2007-11-29T01:33:26Z","lastAt":"2007-12-01T02:37:22Z","messageCount":2,"participants":["Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61352","messageId":"Pine.LNX.4.64.0711290122440.27959@racer.site","threadId":"11055","inReplyTo":null,"subject":"To push into a non-bare repository, or not to push into it...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-29T01:33:26Z","receivedAt":"2007-11-29T01:33:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nhow about resolving this recurring subject of discussion by introducing a \nconfig variable, say \"branch.allowPushingIntoHEAD\".  We'd teach git-init \nto set it to \"false\", and receive-pack would refuse to update HEAD if it \nis \"false\", _unless_ core.bare = true.\n\nOf course, we would default the value to \"false\" to leave existing setups \nfunctional.\n\nHowever, if it is \"true\" (and core.bare is not true) -- which would need \nuser interaction to explicitely set it -- receive-pack would also make \nsure that the working tree is clean (locking the index for the complete \noperation), and call \"read-tree -u -m HEAD\" in the end.\n\nBy refusing the update we would be able to give users a severe *WARNING*, \nbut a hint how to put their HEAD in the noose.\n\nI'd do a patch, but I am 1) tired, and 2) more thinking about that \ngit-repack enhancement for repo.or.cz.\n\nCiao,\nDscho\n"},{"id":"61551","messageId":"7v63zj87j1.fsf@gitster.siamese.dyndns.org","threadId":"11055","inReplyTo":"Pine.LNX.4.64.0711290122440.27959@racer.site","subject":"Re: To push into a non-bare repository, or not to push into it...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-01T02:37:22Z","receivedAt":"2007-12-01T02:37:22Z","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> how about resolving this recurring subject of discussion by introducing a \n> config variable, say \"branch.allowPushingIntoHEAD\".  We'd teach git-init \n> to set it to \"false\", and receive-pack would refuse to update HEAD if it \n> is \"false\", _unless_ core.bare = true.\n>\n> Of course, we would default the value to \"false\" to leave existing setups \n> functional.\n\nPerhaps that could be a reasonable compromise, except that it does not\nfeel right to assume that new repositories are used by new users.\nPeople who have been been trained to expect \"git push\" to checked out\nbranches always work (and they know \"git reset --hard\" or have\nequivalent post-update hook) will wonder why their push into a new clone\ndoes not work while their push into existing ones does.\n\nBut with a good diagnosis to pushers when receive-pack refuses a push\nfor this reason, I do not think that should be too much of a problem.\n\nUpon REF_STATUS_REMOTE_REJECT, the message on \"ng \" line will be given\nby send-pack to the pusher, so the infrastructure to do so is already\nthere, I think.  We need to utilize it when we implement your\nsuggestion.\n"}]}