specifying "fast-forward" only in git-pull

Hi, I'm looking through the documentation on git-pull and
I see that I can specify a particular (sequence of) merge
strategies, but I can't see a way to say "only do a fast
forward, stopping if a fast forward doesn't apply".
(Fast-forward doesn't appear to be a named strategy,
which is why I can't use it with -s). Is there a way to
do this?

Rationale: I have a repository on several machines that
are synchronised via usb-stick. 99.9% of the time a fast
forward is all that is needed, and for scripting the
synchronisation I'd like to restrict it so that only
fast-forwards can happen automatically and everything
else I have to do by invoking git myself. (Somehow I managed to get
a merge that gave a weird result without me actually
noticing for a couple of days, which combined with
my chronological version scripts seemed to put new
trees onto an unnamed branch. I've got the repo sorted
out now, but I want to avoid the same issue in future.)

Many thanks for any help.
-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould

David Tweed [off-list ref] wrote:

Hi, I'm looking through the documentation on git-pull and
I see that I can specify a particular (sequence of) merge
strategies, but I can't see a way to say "only do a fast
forward, stopping if a fast forward doesn't apply".
(Fast-forward doesn't appear to be a named strategy,
which is why I can't use it with -s). Is there a way to
do this?

Rationale: I have a repository on several machines that
are synchronised via usb-stick. 99.9% of the time a fast
forward is all that is needed, and for scripting the
synchronisation I'd like to restrict it so that only
fast-forwards can happen automatically and everything
else I have to do by invoking git myself. (Somehow I managed to get
a merge that gave a weird result without me actually
noticing for a couple of days, which combined with
my chronological version scripts seemed to put new
trees onto an unnamed branch. I've got the repo sorted
out now, but I want to avoid the same issue in future.)

If you are running a pull automatically and want to make sure its
strictly a fast-forward, use something like:

	git fetch &&
	b=$(git merge-base FETCH_HEAD HEAD) &&
	test $b = $(git rev-parse HEAD^0) &&
	git merge FETCH_HEAD

The idea here is that if the merge base of the current branch and
the incoming branch is the current branch, then the incoming branch
is a superset of the current branch, and git-merge will perform
a fast-forward.

-- 
Shawn.