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
--
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