{"thread":{"id":"3250","subject":"git-http-push and hooks","startedAt":"2006-02-06T20:52:03Z","lastAt":"2006-02-07T23:48:12Z","messageCount":12,"participants":["Bertrand Jacquin (Beber)","Nick Hengeveld","Fredrik Kuivinen","Bertrand Jacquin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15637","messageId":"20060206205203.GA20973@guybrush.melee","threadId":"3250","inReplyTo":null,"subject":"git-http-push and hooks","fromName":"Bertrand Jacquin (Beber)","fromEmail":"beber@guybrush.melee","sentAt":"2006-02-06T20:52:03Z","receivedAt":"2006-02-06T20:52:03Z","isPatch":false,"sender":{"key":"beber@guybrush.melee","avatar":null},"body":"Hi,\n\nJust a silly question :\nWhy aren't excute hooks/* (with +x perms) when I do a git-http-push ?\nAlso if i push with cg-push on the same repo but with git+ssh\nprotocol, hooks are execute.\n\nThanks\n\n-- \n/* Beber : beber (AT) setibzh (DOT) com\n * http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}\n * Guybrush @ Melee */\n"},{"id":"15648","messageId":"20060206232231.GK3873@reactrix.com","threadId":"3250","inReplyTo":"20060206205203.GA20973@guybrush.melee","subject":"Re: git-http-push and hooks","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2006-02-06T23:22:31Z","receivedAt":"2006-02-06T23:22:31Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Mon, Feb 06, 2006 at 09:52:03PM +0100, Bertrand Jacquin (Beber) wrote:\n\n> Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?\n> Also if i push with cg-push on the same repo but with git+ssh\n> protocol, hooks are execute.\n\nHooks must run on the destination server when you're doing a push. If\nyou use the git+ssh protocol, that server is running a git daemon that\nknows how to execute hooks; if you use the http/DAV protocol, that\nserver does not.\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"15688","messageId":"20060207195458.GA7217@c165.ib.student.liu.se","threadId":"3250","inReplyTo":"20060206232231.GK3873@reactrix.com","subject":"Re: git-http-push and hooks","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2006-02-07T19:54:58Z","receivedAt":"2006-02-07T19:54:58Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Mon, Feb 06, 2006 at 03:22:31PM -0800, Nick Hengeveld wrote:\n> On Mon, Feb 06, 2006 at 09:52:03PM +0100, Bertrand Jacquin (Beber) wrote:\n> \n> > Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?\n> > Also if i push with cg-push on the same repo but with git+ssh\n> > protocol, hooks are execute.\n> \n> Hooks must run on the destination server when you're doing a push. If\n> you use the git+ssh protocol, that server is running a git daemon that\n> knows how to execute hooks; if you use the http/DAV protocol, that\n> server does not.\n> \n\nI know basically nothing about DAV, but wouldn't it be possible to\nhave a CGI-script which executes the hooks upon the client's request?\n\n- Fredrik\n"},{"id":"15689","messageId":"20060207202351.GA3833@reactrix.com","threadId":"3250","inReplyTo":"20060207195458.GA7217@c165.ib.student.liu.se","subject":"Re: git-http-push and hooks","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2006-02-07T20:23:51Z","receivedAt":"2006-02-07T20:23:51Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Tue, Feb 07, 2006 at 08:54:58PM +0100, Fredrik Kuivinen wrote:\n\n> I know basically nothing about DAV, but wouldn't it be possible to\n> have a CGI-script which executes the hooks upon the client's request?\n\nIt would, although if custom software can be run on the server you might\nas well run the git daemon.\n\nThere are options for a DAV-only environment though. While the hooks\nthemselves can't be run, git-http-push can be modified to update the\nremote pack and ref info (although it's not clear to me under what\nconditions it should do so...) DAV-specific versions of pack\nmanagement utilities are feasible as well.\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"15692","messageId":"4fb292fa0602071251y173efc4dw98fe1e4c035741a3@mail.gmail.com","threadId":"3250","inReplyTo":"20060207195458.GA7217@c165.ib.student.liu.se","subject":"Re: git-http-push and hooks","fromName":"Bertrand Jacquin","fromEmail":"beber.mailing@gmail.com","sentAt":"2006-02-07T20:51:25Z","receivedAt":"2006-02-07T20:51:25Z","isPatch":false,"sender":{"key":"beber.mailing@gmail.com","avatar":null},"body":"On 2/7/06, Fredrik Kuivinen wrote:\n> On Mon, Feb 06, 2006 at 03:22:31PM -0800, Nick Hengeveld wrote:\n> > On Mon, Feb 06, 2006 at 09:52:03PM +0100, Bertrand Jacquin (Beber) wrote:\n> >\n> > > Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?\n> > > Also if i push with cg-push on the same repo but with git+ssh\n> > > protocol, hooks are execute.\n> >\n> > Hooks must run on the destination server when you're doing a push. If\n> > you use the git+ssh protocol, that server is running a git daemon that\n> > knows how to execute hooks; if you use the http/DAV protocol, that\n> > server does not.\n> >\n>\n> I know basically nothing about DAV, but wouldn't it be possible to\n> have a CGI-script which executes the hooks upon the client's request?\n\nSvn can execute hooks :/ But maybe this is implemented in -D SVN\nmodule for Apache. Donno\n\n>\n> - Fredrik\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n--\nBeber\n#e.fr@freenode\n"},{"id":"15693","messageId":"20060207205709.GB7217@c165.ib.student.liu.se","threadId":"3250","inReplyTo":"20060207202351.GA3833@reactrix.com","subject":"Re: git-http-push and hooks","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2006-02-07T20:57:11Z","receivedAt":"2006-02-07T20:57:11Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Tue, Feb 07, 2006 at 12:23:51PM -0800, Nick Hengeveld wrote:\n> On Tue, Feb 07, 2006 at 08:54:58PM +0100, Fredrik Kuivinen wrote:\n> \n> > I know basically nothing about DAV, but wouldn't it be possible to\n> > have a CGI-script which executes the hooks upon the client's request?\n> \n> It would, although if custom software can be run on the server you might\n> as well run the git daemon.\n\nYou can't push to a git daemon, can you?\n\nFurthermore, if the user has a working http/DAV server installed it\nmight be the case that she prefers to use that one instead of\ninstalling a new daemon.\n\n- Fredrik\n"},{"id":"15695","messageId":"4fb292fa0602071302p551aca02j53d40e3f8e25ff8a@mail.gmail.com","threadId":"3250","inReplyTo":"20060207205709.GB7217@c165.ib.student.liu.se","subject":"Re: git-http-push and hooks","fromName":"Bertrand Jacquin","fromEmail":"beber.mailing@gmail.com","sentAt":"2006-02-07T21:02:42Z","receivedAt":"2006-02-07T21:02:42Z","isPatch":false,"sender":{"key":"beber.mailing@gmail.com","avatar":null},"body":"On 2/7/06, Fredrik Kuivinen wrote:\n> On Tue, Feb 07, 2006 at 12:23:51PM -0800, Nick Hengeveld wrote:\n> > On Tue, Feb 07, 2006 at 08:54:58PM +0100, Fredrik Kuivinen wrote:\n> >\n> > > I know basically nothing about DAV, but wouldn't it be possible to\n> > > have a CGI-script which executes the hooks upon the client's request?\n> >\n> > It would, although if custom software can be run on the server you might\n> > as well run the git daemon.\n>\n> You can't push to a git daemon, can you?\n>\n> Furthermore, if the user has a working http/DAV server installed it\n> might be the case that she prefers to use that one instead of\n> installing a new daemon.\n\nPersonaly is use http because at work i've a $$@#! proxy and allow dav\nand nothing else.\nCould you push over http/proxy with gitdaemon ? Isn't it just a read\nonly method ?\n\n>\n> - Fredrik\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n--\nBeber\n#e.fr@freenode\n"},{"id":"15694","messageId":"7vwtg6uaw6.fsf@assigned-by-dhcp.cox.net","threadId":"3250","inReplyTo":"20060207202351.GA3833@reactrix.com","subject":"Re: git-http-push and hooks","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-07T21:17:13Z","receivedAt":"2006-02-07T21:17:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Hengeveld writes:\n\n> There are options for a DAV-only environment though. While the hooks\n> themselves can't be run, git-http-push can be modified to update the\n> remote pack and ref info (although it's not clear to me under what\n> conditions it should do so...) DAV-specific versions of pack\n> management utilities are feasible as well.\n\nIf the server info updates is the _only_ problem, then perhaps\nthat would be the easiest and cleanest. Whenever you update or\nadd a ref you would need to update info/refs (otherwise\nls-remote would not give you the latest info), and whenever you\nrepack you would need to update objects/info/packs.\n\nYou may probably want to have a CGI to allow you manage the\nrepository remotely anyway, to trigger a repack or remove a\nstale branch head, for example. Once you go that route maybe\nhaving the CGI to do something like the pack protocol for more\nefficient transfer might become more attractive.\n"},{"id":"15699","messageId":"20060207224551.GB3833@reactrix.com","threadId":"3250","inReplyTo":"7vwtg6uaw6.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-http-push and hooks","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2006-02-07T22:45:51Z","receivedAt":"2006-02-07T22:45:51Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Tue, Feb 07, 2006 at 01:17:13PM -0800, Junio C Hamano wrote:\n\n> If the server info updates is the _only_ problem, then perhaps\n> that would be the easiest and cleanest. Whenever you update or\n> add a ref you would need to update info/refs (otherwise\n> ls-remote would not give you the latest info), and whenever you\n> repack you would need to update objects/info/packs.\n\nWhat happens if someone else updates a ref and it no longer matches your\nlocal ref? Should the push scan the remote versions of all local refs\nand update whatever doesn't match?\n\n> You may probably want to have a CGI to allow you manage the\n> repository remotely anyway, to trigger a repack or remove a\n> stale branch head, for example. Once you go that route maybe\n> having the CGI to do something like the pack protocol for more\n> efficient transfer might become more attractive.\n\nThat's an option if the user has the ability to install CGI scripts on the\nDAV server, which doesn't seem like it will always be true. Perhaps it\nwould make sense to do both:\n\n- add a git-http-repack command that works in a DAV-only environment\n- add a CGI script to provide remote management, and a config\n setting to git-http-push for the remote management URL\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"15700","messageId":"7vpslysqcb.fsf@assigned-by-dhcp.cox.net","threadId":"3250","inReplyTo":"20060207224551.GB3833@reactrix.com","subject":"Re: git-http-push and hooks","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-07T23:26:28Z","receivedAt":"2006-02-07T23:26:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Hengeveld writes:\n\n> What happens if someone else updates a ref and it no longer\n> matches your local ref? Should the push scan the remote\n> versions of all local refs and update whatever doesn't match?\n\nIf I and you clone from a shared repository at the same time, I\ndid my development while you did your own on top of that same\ncommit without pulling from the repository further, and I\nuploaded my changes to update the ref, what should happen to you\nonce you are ready to push?\n\nIs that what being asked?\n\nIf so, I think the sensible thing to do is to reject your push\nand suggest you to pull first, just like the git native protocol\npush does. That pull would end up first merging my changes to\nyour work in your repository, and then you can push the result\nback to the shared repository. Otherwise you would lose my\nchanges.\n\nThe criteria to allow a push is obviously not \"no longer\nmatches\" because in the above scenario what both you and I\nfetched from the shared repository is something that is an\nancestor of what each of us is trying to push. The first one\nshould succeed -- it is pushing a new commit that is a\ndescendant of what is currently the head of the shared\nrepository. The latter one fails because at that time the head\nof the shared repository is not an ancestor of what you are\ntrying to push.\n\nIf you are asking about a race, yes there is a race condition\nand you have to be careful. The native protocol does it like\nso (receive-pack.c):\n\n 1. At the shared repository grab the current head;\n\n 2. Examine what is being pushed. Is it a descendant of the one\n we grabbed in the previous step? If not, reject.\n\n 3. Lock the ref, grab the current head again, make sure it is\n still the same as what we got in the first step, update it\n with what was pushed, and then unlock.\n\nI think you may be able to do a similar check on the client\nside, if DAV allows locking resources at least for a brief\nperiod.\n\nIf you are asking about updating local tracking branch for the\nremote ref after a successful push, I think that is an optional\nfeature and is entirely up to you. For example, if your\nworkflow is to fetch from the shared repository into origin,\nmerge that into master, work on master, and then push the result\nto the master branch of the shared repository, you could update\nyour origin with the commit you just pushed. This lets you\npretend as if you fetched from there immediately after your\nsuccessful push.\n\nI think Cogito does it that way, but I personally found leaving\nthe tracing ref as-is after a push more useful, so I left\ngit-push not to do so. For example, leaving when to update\n\"origin\" up to me allows me do run \"git log origin..master\" to\nwrite the \"what's new in git.git\" message after I push. Of\ncourse the same thing can be done by running the git log before\nI push, so there is not much practical difference either way.\n"},{"id":"15701","messageId":"7v8xsmspnh.fsf@assigned-by-dhcp.cox.net","threadId":"3250","inReplyTo":"4fb292fa0602071302p551aca02j53d40e3f8e25ff8a@mail.gmail.com","subject":"Re: git-http-push and hooks","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-07T23:41:22Z","receivedAt":"2006-02-07T23:41:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bertrand Jacquin writes:\n\n> On 2/7/06, Fredrik Kuivinen wrote:\n>> You can't push to a git daemon, can you?\n>>\n>> Furthermore, if the user has a working http/DAV server installed it\n>> might be the case that she prefers to use that one instead of\n>> installing a new daemon.\n>\n> Personaly is use http because at work i've a $$@#! proxy and allow dav\n> and nothing else.\n> Could you push over http/proxy with gitdaemon ? Isn't it just a read\n> only method ?\n\nI think you are agreeing with what Fredrik said. git-daemon is\na read-only thing. You would want to SSH into the repository\nmachine.\n\nIf you are using git at work for work, and the benefit git gives\nyou outweigh the cost and trouble to modify the proxy and/or\nfirewalling settings, maybe you can convince your management to\nallow you to SSH out to make you more productive? That way you\ncan use git-push over native git protocol.\n\nIf you are using git while at work but not for work, then maybe\nI should not be giving an advice ;-).\n"},{"id":"15702","messageId":"20060207234812.GC3833@reactrix.com","threadId":"3250","inReplyTo":"7vpslysqcb.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-http-push and hooks","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2006-02-07T23:48:12Z","receivedAt":"2006-02-07T23:48:12Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Tue, Feb 07, 2006 at 03:26:28PM -0800, Junio C Hamano wrote:\n\n> If I and you clone from a shared repository at the same time, I\n> did my development while you did your own on top of that same\n> commit without pulling from the repository further, and I\n> uploaded my changes to update the ref, what should happen to you\n> once you are ready to push?\n> \n> Is that what being asked?\n> \n> If so, I think the sensible thing to do is to reject your push\n> and suggest you to pull first, just like the git native protocol\n> push does. That pull would end up first merging my changes to\n> your work in your repository, and then you can push the result\n> back to the shared repository. Otherwise you would lose my\n> changes.\n\nMakes sense, and it's the way http-push already works for heads. I\nguess where I'm not clear is tags - since info/refs is generated by\nrecursing through everything in the refs/ subdirectory. I think I just\nanswered my own question though; http-push needs to recurse through\neverything under refs/ on the remote end to generate the new info/refs\nfile. That just leaves the problem that http-push doesn't push tags\nyet.\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"}]}