its working now. thank for the help. can a notification be set for a single branch?
On Tue, Aug 16, 2011 at 12:30 PM, pavan kumar <[email protected]>wrote: > i worked on it made a copy of content of post-receive-email to post-receive > and tried the script > > prjct-dir/.git> cat >hooks/post-receive <<END > ? #!/bin/sh > ? echo 'im working' >/tmp/myhook > ? END > > nothing is working. what would be the problem. > > On Fri, Aug 12, 2011 at 6:13 PM, pavan kumar <[email protected]>wrote: > >> instead of linking the post-receive-email, i can copy that it to >> post-receive, i will try doing this. >> if i do below will replace the script will it work? >> >> prjct-dir/.git> cat >hooks/post-receive <<END >> ? #!/bin/sh >> ? echo 'i'm working' >/tmp/myhook >> ? END >> >> On Fri, Aug 12, 2011 at 4:26 PM, Konstantin Khomoutov < >> [email protected]> wrote: >> >>> On Fri, 12 Aug 2011 11:06:12 +0530 >>> pavan kumar <[email protected]> wrote: >>> >>> > once let me clarify what i'm doing. >>> > as in this link >>> > http://anonscm.debian.org/git/pkg-nvidia/git-commit-notice i changed >>> > the mode of post-receive-email >>> > in /usr/share/doc/git-core/contrib/hooks/ then i linked it with the >>> > post-receive file in my prjct-dir/.git/hooks and then >>> > prjct-dir/.git> cat >hooks/post-receive <<END >>> > ? #!/bin/sh >>> > ? echo 'i'm working' >tmp/myhook >>> > ? END >>> > >>> > i got a error >>> > >>> > hooks/post-receive: Permission denied. >>> > >>> > i think this is because of the link. >>> >>> Unlikely. Hard links are trasparent by definition, and for >>> symbolic links POSIX semantics are that most kinds of accesses to the >>> filesystem objects count links as transparent (and permission checking >>> is not performed on the links themselves). >>> Hence, if you hardlinked, check the permissions on the resulting file; >>> if you made a soft link, check the permissions of the target file. >>> >>> You have to understand that to execute a script, the process must have >>> both read and execute permissions, and the read permission on the >>> containing directory and all its parents (this is not usually a problem >>> unless you have a really botched setup). Also note that the set of >>> permissions (owner, group, or others) that will be used for checking >>> clearly depends on which set the process's credentials will be mapped >>> onto. As you can see this is all about entry-level knowledge of >>> Unix-like systems and has nothing to do with Git. >>> >>> Also note that the second line of your test script contains two errors: >>> unclosed ' and the absence of the / before "tmp" which will make the >>> shell interpret that path as relative to the current directory of the >>> shell executing the script (and will most probably result in an error >>> unless a directory named "tmp" happens to exist there). >>> >>> > is this the process to do a hook? >>> Personally, I'd just copy the script over to the hooks directory instead >>> of linking to it. Messing with permissions on files presumably >>> installed by an OS package files appears to be a wrong idea to me. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
