Re: git push to a non-bare repository

From: Theodore Tso <tytso@mit.edu>
Date: Mar 19, 2007, 02:47 UTC
Message-ID: <20070319024744.GD11371@thunk.org>
In-Reply-To: <20070319022143.GF20658@spearce.org>

On Sun, Mar 18, 2007 at 10:21:43PM -0400, Shawn O. Pearce wrote:

Show 9 quoted lines

> Junio C Hamano <junkio@cox.net> wrote:
> > Theodore Tso <tytso@mit.edu> writes:
> > 
> > > Is it at all possible to figure out <commit-id-before-the-push>?  It
> > > seems the answer is no, and I suspect that's a bug.
> > 
> > Doesn't update hook get pre- and post- commit object name?
> 
> Yes, and the same is true in the new post-receive hook.

In my comments, I was observing that *after* the push had succeeded, there was no way to find the commit-id-before-the-push, since neither the reflog nor ORIG_HEAD is getting updated. Is there a good reason why not? Would you accept a patch which caused the reflog and possibly ORIG_HEAD to be updated on the remote side of the push?

When I was talking about a hook to enforce the BitKeeper semantics, the question is whether we have enough to enforce the following:

	* Only accept the push if it will result in a fast-forward
		merge (and if not, tell the user to do a git pull, merge
		locally, and then redo the git push)
	* Only accept the push if there are no locally modified files
		that would be affected when the working directory is
		updated to reflect the new HEAD

I don't think there's any easy way to determine if these two criteria would be met besides trying to actually do the merge, and if it fails atomically back out to the original starting point, right? Or am I missing something painfully obvious?

Since one of the applications where I might want to do something like this is a push a web site being maintained by git (where I don't want any the result of the interim attempted to merge to accidentally get seen by the web server), probably in order to do this right I'd have to have the hook script do a cp -rl of the repository+working tree to some scratch space, try to do the merge and update of the working tree, and if it succeeds, allow it to happen for real in the "live" tree, and if not, fail the merge. This seems awfully kludgy; is there some other way?

						- Ted