From: Junio C Hamano <gitster@pobox.com>
To: Mike Lewis <mike@mplew.is>
Cc: git@vger.kernel.org
Subject: Re: Server-side hooks on non-bare repository
Date: Mon, 06 Mar 2017 13:42:03 -0800 [thread overview]
Message-ID: <xmqq1suankus.fsf@junio-linux.mtv.corp.google.com> (raw)
In-Reply-To: <719CE082-14AB-4E18-AE7D-7D2A818CF499@mplew.is> (Mike Lewis's message of "Fri, 3 Mar 2017 19:10:05 -0500")
Mike Lewis <mike@mplew.is> writes:
> I’m having some issues with using server-side hooks when pushing
> to a non-bare repository. In my git config, I have
> `receive.denyCurrentBranch` set to `updateInstead`, which behaves
> as expected, and updates the current working tree when the current
> branch is pushed to. However, attempting to process those changes
> with pre-receive and post-receive hooks results in some unexpected
> behavior regarding the current working directory of the scripts
> and using git commands.
The pre-receive hook is to inspect the objects and ref updates and
say "yes, allow it" or "no, refuse it"---you are not supposed to do
anything else, so even though what processing you are interested in
doing in your "attempting to process" is unclear, this hook is not
what you want to use anyway.
The post-receive hook is a more interesting case. It is called only
after everything finishes, so it is like running a custom script
after "git push" is processed.
> I’ve tested these issues using both git
> 2.11 and 2.12 on various systems (macOS and CentOS), and get the
> same behavior each time.
That is a very good news, as I do not think at least in the past few
years we planned to change the established behaviour of the hook.
> 1. When using a non-bare repository, I would expect the the
> working directory of the hook to be the root directory of the
> working tree,...
> 2. While running the hooks, git treats the repository as being
> bare, regardless of whether it actually is.
Yes, and it is unlikely that the behaviour wrt to where $cwd is
during the hook's execution will ever change; otherwise existing
scripts that know what the rule is (i.e. the rule you figured out in
2.) will be broken. denycurrent=updateinstead *is* an odd-man out,
and its processing is purely internal---its addition does not mean
hook authors are suddenly required to do things differently
depending on bare/non-bare-ness of the repository.
next prev parent reply other threads:[~2017-03-06 21:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-04 0:10 Server-side hooks on non-bare repository Mike Lewis
2017-03-06 21:42 ` Junio C Hamano [this message]
2017-03-06 22:33 ` Mike Lewis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1suankus.fsf@junio-linux.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mike@mplew.is \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).