Re: process committed files in post-receive hook

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/10/2011 4:29 AM, Hao wrote:
Hi guys,

I am writing a post-receive hook in Python that examines the content
of some files (the HEAD rev). Because the repo is a bare one on the
server. My current approach is to check out a working copy on the
server and run 'git pull' in post- receive to get the most up-to-date
version, and then process files in the working copy.

I have two questions. First, is there a way that I can access file
content in a bare repo without checking out a working copy? If this
is not possible, my approach would be reasonable. However, when 'git
pull' was called in the python script post-receive when a commit
occurs, it gives an error.

remote: fatal: Not a git repository: '.'

The call in python is

subprocess.Popen(["git", "pull"],
cwd="/Users/git/ts.git.workingcopy")

I read from a post (http://stackoverflow.com/questions/4043609/) that
GIT_DIR is causing this error. Is it safe to unset GIT_DIR in
post-receive?

The specific processing you intend to perform on the files would
determine which of the access techniques is appropriate for you.
Generally speaking, I think a checkout in a non-bare repo makes sense. You could limit it to a shallow clone (see git-clone manpage) to save space.

Another way to get the files is git-archive (creates tar file), that you could extract to a dir for processing.

In both cases, you need to consider the default permissions in play with git-checkout and git-archive if permissions are important in your processing.

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]