Theodore Tso <tytso@xxxxxxx> wrote: > 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? Ah, my bad, it defaults to false: static int deny_non_fast_forwards = 0; I should have known better, as I run a 1.5.x (aka 'next') server for a workgroup and I never have that set, but use instead a complex update hook that decides if a fast-forward is required or not. > > > * 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 > > > > 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". git-diff $old $new | git-apply --index ? If the patch does not apply, nothing gets updated. If it does apply, the index is also updated and stat data updated. OK, it doesn't quite handle every case, as sometimes a patch will reject but the internal 3-way merge from xdiff that is called by merge-recursive will succeed, but this does protect your working tree and doesn't require making a temporary copy. Of course another possible approach is to stuff the entire working directory into a temporary tree, and then merge. If the merge doesn't work, you can reset to the temporary tree. Unfortunately the working directory is "in flux" during that process... its not atomic. -- Shawn. - 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