Theodore Tso <tytso@mit.edu> wrote:
quoted text
> 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.
 
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
> > 
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html