On Sun, Mar 18, 2007 at 10:56:03PM -0400, Shawn O. Pearce wrote: > > 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? > > * 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html