Subject: Re: post-update to stash after push to non-bare current branch

From: Neal Kreitzinger <[email-masked]>
Date: Wed, 18 Jan 2012 12:51:25 -0600

On 1/18/2012 12:33 PM, Neal Kreitzinger wrote:
> On 1/18/2012 11:53 AM, Neal Kreitzinger wrote:
>> We use the worktree of git-repos as the webroot for virtual hosts
>> assigned
>> to ports so we can directly test changes to dev and test git-repos. We
>> have
>> some developers who want to develop offline on laptops and push to these
>> non-bare repos so they can test their changes. My plan is to set
>> receive.denyCurrentBranch = warn, and then use the post-update hook on
>> the
>> remote non-bare to do a stash of the worktree and index. My assumption is
>> that post-update hook only executes after a successful push. Correct? I
>> only want to stash the non-bare remote work-tree and index after a
>> successful push to it (effectively doing a git-reset --hard, but also
>> keeping any changes to the worktree/index of the non-bare remote as a
>> safety
>> in case someone does directly make uncommitted changes on the non-bare
>> remote.)
>>
> If I manually run git-stash on the non-bare remote after pushing to it
> from a clone (receive.denyCurrentBranch=warn) it works as expected and
> leaves the worktree and index matching the new HEAD. However, when
> post-update runs the git-stash is leaves the worktree dirty. (git 1.7.1)
>
hooks/post-update was:

git stash save
echo "worktree+index of non-bare remote current branch stashed for safety"

it created the stash and echoed the message. However, as stated earlier, 
the worktree is still dirty.  I then manually run git-reset --hard and 
that makes it clean (worktree, index, HEAD match).  However, if I add 
that to the hook it still leaves dirty worktree (index matches HEAD, but 
worktree doesn't match index)

hooks/post-update is:

git stash save
echo "worktree+index of non-bare remote current branch stashed for safety"
git reset --hard
echo "git-reset --hard on current remote branch to ensure clean state"

message is echoed, but git-reset --hard does not appear to have really 
worked. (git 1.7.1)

v/r,
neal