git-http-push and hooks

git-http-push and hooks

[Bertrand Jacquin (Beber)]

Hi,

Just a silly question :
Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?
Also if i push with cg-push on the same repo but with git+ssh
protocol, hooks are execute.

Thanks

-- 
/* Beber : beber (AT) setibzh (DOT) com
 * http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
 * Guybrush @ Melee */

Re: git-http-push and hooks

[Nick Hengeveld]

On Mon, Feb 06, 2006 at 09:52:03PM +0100, Bertrand Jacquin (Beber) wrote:

> Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?
> Also if i push with cg-push on the same repo but with git+ssh
> protocol, hooks are execute.

Hooks must run on the destination server when you're doing a push.  If
you use the git+ssh protocol, that server is running a git daemon that
knows how to execute hooks; if you use the http/DAV protocol, that
server does not.

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.

Re: git-http-push and hooks

[Fredrik Kuivinen]

On Mon, Feb 06, 2006 at 03:22:31PM -0800, Nick Hengeveld wrote:
> On Mon, Feb 06, 2006 at 09:52:03PM +0100, Bertrand Jacquin (Beber) wrote:
> 
> > Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?
> > Also if i push with cg-push on the same repo but with git+ssh
> > protocol, hooks are execute.
> 
> Hooks must run on the destination server when you're doing a push.  If
> you use the git+ssh protocol, that server is running a git daemon that
> knows how to execute hooks; if you use the http/DAV protocol, that
> server does not.
> 

I know basically nothing about DAV, but wouldn't it be possible to
have a CGI-script which executes the hooks upon the client's request?

- Fredrik

Re: git-http-push and hooks

[Nick Hengeveld]

On Tue, Feb 07, 2006 at 08:54:58PM +0100, Fredrik Kuivinen wrote:

> I know basically nothing about DAV, but wouldn't it be possible to
> have a CGI-script which executes the hooks upon the client's request?

It would, although if custom software can be run on the server you might
as well run the git daemon.

There are options for a DAV-only environment though.  While the hooks
themselves can't be run, git-http-push can be modified to update the
remote pack and ref info (although it's not clear to me under what
conditions it should do so...)  DAV-specific versions of pack
management utilities are feasible as well.

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.

Re: git-http-push and hooks

[Bertrand Jacquin]

On 2/7/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> On Mon, Feb 06, 2006 at 03:22:31PM -0800, Nick Hengeveld wrote:
> > On Mon, Feb 06, 2006 at 09:52:03PM +0100, Bertrand Jacquin (Beber) wrote:
> >
> > > Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?
> > > Also if i push with cg-push on the same repo but with git+ssh
> > > protocol, hooks are execute.
> >
> > Hooks must run on the destination server when you're doing a push.  If
> > you use the git+ssh protocol, that server is running a git daemon that
> > knows how to execute hooks; if you use the http/DAV protocol, that
> > server does not.
> >
>
> I know basically nothing about DAV, but wouldn't it be possible to
> have a CGI-script which executes the hooks upon the client's request?

Svn can execute hooks :/ But maybe this is implemented in -D SVN
module for Apache. Donno

>
> - Fredrik
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
Beber
#e.fr@freenode

Re: git-http-push and hooks

[Fredrik Kuivinen]

On Tue, Feb 07, 2006 at 12:23:51PM -0800, Nick Hengeveld wrote:
> On Tue, Feb 07, 2006 at 08:54:58PM +0100, Fredrik Kuivinen wrote:
> 
> > I know basically nothing about DAV, but wouldn't it be possible to
> > have a CGI-script which executes the hooks upon the client's request?
> 
> It would, although if custom software can be run on the server you might
> as well run the git daemon.

You can't push to a git daemon, can you?

Furthermore, if the user has a working http/DAV server installed it
might be the case that she prefers to use that one instead of
installing a new daemon.

- Fredrik

Re: git-http-push and hooks

[Bertrand Jacquin]

On 2/7/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> On Tue, Feb 07, 2006 at 12:23:51PM -0800, Nick Hengeveld wrote:
> > On Tue, Feb 07, 2006 at 08:54:58PM +0100, Fredrik Kuivinen wrote:
> >
> > > I know basically nothing about DAV, but wouldn't it be possible to
> > > have a CGI-script which executes the hooks upon the client's request?
> >
> > It would, although if custom software can be run on the server you might
> > as well run the git daemon.
>
> You can't push to a git daemon, can you?
>
> Furthermore, if the user has a working http/DAV server installed it
> might be the case that she prefers to use that one instead of
> installing a new daemon.

Personaly is use http because at work i've a $$@#! proxy and allow dav
and nothing else.
Could you push over http/proxy with gitdaemon ? Isn't it just a read
only method ?

>
> - Fredrik
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
Beber
#e.fr@freenode

Re: git-http-push and hooks

[Junio C Hamano]

Nick Hengeveld <nickh@reactrix.com> writes:

> There are options for a DAV-only environment though.  While the hooks
> themselves can't be run, git-http-push can be modified to update the
> remote pack and ref info (although it's not clear to me under what
> conditions it should do so...)  DAV-specific versions of pack
> management utilities are feasible as well.

If the server info updates is the _only_ problem, then perhaps
that would be the easiest and cleanest.  Whenever you update or
add a ref you would need to update info/refs (otherwise
ls-remote would not give you the latest info), and whenever you
repack you would need to update objects/info/packs.

You may probably want to have a CGI to allow you manage the
repository remotely anyway, to trigger a repack or remove a
stale branch head, for example.  Once you go that route maybe
having the CGI to do something like the pack protocol for more
efficient transfer might become more attractive.

Re: git-http-push and hooks

[Nick Hengeveld]

On Tue, Feb 07, 2006 at 01:17:13PM -0800, Junio C Hamano wrote:

> If the server info updates is the _only_ problem, then perhaps
> that would be the easiest and cleanest.  Whenever you update or
> add a ref you would need to update info/refs (otherwise
> ls-remote would not give you the latest info), and whenever you
> repack you would need to update objects/info/packs.

What happens if someone else updates a ref and it no longer matches your
local ref?  Should the push scan the remote versions of all local refs
and update whatever doesn't match?

> You may probably want to have a CGI to allow you manage the
> repository remotely anyway, to trigger a repack or remove a
> stale branch head, for example.  Once you go that route maybe
> having the CGI to do something like the pack protocol for more
> efficient transfer might become more attractive.

That's an option if the user has the ability to install CGI scripts on the
DAV server, which doesn't seem like it will always be true.  Perhaps it
would make sense to do both:

- add a git-http-repack command that works in a DAV-only environment
- add a CGI script to provide remote management, and a config
  setting to git-http-push for the remote management URL

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.

Re: git-http-push and hooks

[Junio C Hamano]

Nick Hengeveld <nickh@reactrix.com> writes:

> What happens if someone else updates a ref and it no longer
> matches your local ref?  Should the push scan the remote
> versions of all local refs and update whatever doesn't match?

If I and you clone from a shared repository at the same time, I
did my development while you did your own on top of that same
commit without pulling from the repository further, and I
uploaded my changes to update the ref, what should happen to you
once you are ready to push?

Is that what being asked?

If so, I think the sensible thing to do is to reject your push
and suggest you to pull first, just like the git native protocol
push does.  That pull would end up first merging my changes to
your work in your repository, and then you can push the result
back to the shared repository.  Otherwise you would lose my
changes.

The criteria to allow a push is obviously not "no longer
matches" because in the above scenario what both you and I
fetched from the shared repository is something that is an
ancestor of what each of us is trying to push.  The first one
should succeed -- it is pushing a new commit that is a
descendant of what is currently the head of the shared
repository.  The latter one fails because at that time the head
of the shared repository is not an ancestor of what you are
trying to push.

If you are asking about a race, yes there is a race condition
and you have to be careful.  The native protocol does it like
so (receive-pack.c):

 1. At the shared repository grab the current head;

 2. Examine what is being pushed.  Is it a descendant of the one
    we grabbed in the previous step?  If not, reject.

 3. Lock the ref, grab the current head again, make sure it is
    still the same as what we got in the first step, update it
    with what was pushed, and then unlock.

I think you may be able to do a similar check on the client
side, if DAV allows locking resources at least for a brief
period.

If you are asking about updating local tracking branch for the
remote ref after a successful push, I think that is an optional
feature and is entirely up to you.  For example, if your
workflow is to fetch from the shared repository into origin,
merge that into master, work on master, and then push the result
to the master branch of the shared repository, you could update
your origin with the commit you just pushed.  This lets you
pretend as if you fetched from there immediately after your
successful push.

I think Cogito does it that way, but I personally found leaving
the tracing ref as-is after a push more useful, so I left
git-push not to do so.  For example, leaving when to update
"origin" up to me allows me do run "git log origin..master" to
write the "what's new in git.git" message after I push.  Of
course the same thing can be done by running the git log before
I push, so there is not much practical difference either way.

Re: git-http-push and hooks

[Junio C Hamano]

Bertrand Jacquin <beber.mailing@gmail.com> writes:

> On 2/7/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
>> You can't push to a git daemon, can you?
>>
>> Furthermore, if the user has a working http/DAV server installed it
>> might be the case that she prefers to use that one instead of
>> installing a new daemon.
>
> Personaly is use http because at work i've a $$@#! proxy and allow dav
> and nothing else.
> Could you push over http/proxy with gitdaemon ? Isn't it just a read
> only method ?

I think you are agreeing with what Fredrik said.  git-daemon is
a read-only thing.  You would want to SSH into the repository
machine.

If you are using git at work for work, and the benefit git gives
you outweigh the cost and trouble to modify the proxy and/or
firewalling settings, maybe you can convince your management to
allow you to SSH out to make you more productive?  That way you
can use git-push over native git protocol.

If you are using git while at work but not for work, then maybe
I should not be giving an advice ;-).

Re: git-http-push and hooks

[Nick Hengeveld]

On Tue, Feb 07, 2006 at 03:26:28PM -0800, Junio C Hamano wrote:

> If I and you clone from a shared repository at the same time, I
> did my development while you did your own on top of that same
> commit without pulling from the repository further, and I
> uploaded my changes to update the ref, what should happen to you
> once you are ready to push?
> 
> Is that what being asked?
> 
> If so, I think the sensible thing to do is to reject your push
> and suggest you to pull first, just like the git native protocol
> push does.  That pull would end up first merging my changes to
> your work in your repository, and then you can push the result
> back to the shared repository.  Otherwise you would lose my
> changes.

Makes sense, and it's the way http-push already works for heads.  I
guess where I'm not clear is tags - since info/refs is generated by
recursing through everything in the refs/ subdirectory.  I think I just
answered my own question though; http-push needs to recurse through
everything under refs/ on the remote end to generate the new info/refs
file.  That just leaves the problem that http-push doesn't push tags
yet.

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.