On Sun, Mar 18, 2007 at 10:56:03PM -0400, Shawn O. Pearce wrote:
quoted text
> > 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)
> 
> Yes, the update hook can detect this.  Actually receive-pack by
> default rejects *all* non-fast-forward pushes, even if the client
> side uses --force.

Ah, so that's controlled by receive.denyNonFastForwards, right?  Cool,
I missed that.  Thanks!!

Documentation/config.txt doesn't say it defaults to true, but from
your comments that is the default?

quoted text
> > 	* 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
> 
> The update hook could also perform this check; test if the ref
> being updated is the current branch, and if so, verify the index and
> working directory is clean.  That's a simple run of git-symbolic-ref
> (to get the current branch) and git-runstatus (to check the index
> and working directory), is it not?
> 
> If git-runstatus exits to indicate the tree is clean (nothing to
> commit) then a simple `read-tree -m -u HEAD $new` should update
> the working directory and index, right?

What git-runstatus will allow me to do is to abort if there are any
local modifications, regardless of whether or not they would conflict
with the working tree update.  The key phrase in my criteria was no
locally modified files "THAT WOULD BE AFFECTED".

What I could do with BitKeeper is that I could modify some file like
schedule.html on my webserver, and then push a changeset from my
laptop to would update sermons.html, and it would allow the push ---
since it would change the file sermons.html, and not touch
schedule.html.

But if I modified schedule.html on my laptop and then committed it,
and *then* try to push that changeset to the webserver, it would abort
since in order to accept the changeset, it would have to update the
working tree, and that would clash with the locally modified
schedule.html file.  At thta point I'd have to login to the webserver,
revert the local modification and bring it back down my laptop and
include it in a proper changeset.

Yeah, I probably shouldn't have ever modified the file locally on the
webserver, but that would sometimes happen when I was in a rush, and
it was nice when it Just Worked.

						- 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