Re: git push to a non-bare repository

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Theodore Tso
Date: Sunday, March 18, 2007 - 7:47 pm

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

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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
git push to a non-bare repository, Matthieu Moy, (Sun Mar 18, 10:31 am)
Re: git push to a non-bare repository, Junio C Hamano, (Sun Mar 18, 12:47 pm)
Re: git push to a non-bare repository, Sam Vilain, (Sun Mar 18, 2:51 pm)
Re: git push to a non-bare repository, Junio C Hamano, (Sun Mar 18, 3:18 pm)
Re: git push to a non-bare repository, Junio C Hamano, (Sun Mar 18, 6:55 pm)
Re: git push to a non-bare repository, Theodore Tso, (Sun Mar 18, 7:00 pm)
Re: git push to a non-bare repository, Shawn O. Pearce, (Sun Mar 18, 7:21 pm)
Re: git push to a non-bare repository, Theodore Tso, (Sun Mar 18, 7:47 pm)
Re: git push to a non-bare repository, Shawn O. Pearce, (Sun Mar 18, 7:56 pm)
Re: git push to a non-bare repository, Theodore Tso, (Sun Mar 18, 8:21 pm)
Re: git push to a non-bare repository, Theodore Tso, (Sun Mar 18, 8:33 pm)
Re: git push to a non-bare repository, Shawn O. Pearce, (Sun Mar 18, 8:47 pm)
Re: git push to a non-bare repository, Shawn O. Pearce, (Sun Mar 18, 8:53 pm)
Re: git push to a non-bare repository, Nicolas Pitre, (Sun Mar 18, 9:08 pm)
Re: git push to a non-bare repository, Junio C Hamano, (Sun Mar 18, 9:14 pm)
Re: git push to a non-bare repository, Theodore Tso, (Sun Mar 18, 11:25 pm)
Re: git push to a non-bare repository, Junio C Hamano, (Sun Mar 18, 11:44 pm)
Re: git push to a non-bare repository, Matthieu Moy, (Mon Mar 19, 2:19 am)
Re: git push to a non-bare repository, Nicolas Pitre, (Mon Mar 19, 8:16 am)
Re: git push to a non-bare repository, Nicolas Pitre, (Mon Mar 19, 8:20 am)
Re: git push to a non-bare repository, Sam Vilain, (Mon Mar 19, 4:58 pm)
Re: git push to a non-bare repository, Junio C Hamano, (Mon Mar 19, 5:49 pm)
Re: git push to a non-bare repository, Junio C Hamano, (Mon Mar 19, 5:54 pm)