"Philip Oakley" <philipoak...@iee.org> writes:

> It's not clear to me that a single default that uses a merge or
> rebase, without a 'stop if' criteria would be of any help in my
> situation.
> My thoughts are that the options on a fetch-pull are for the branch to
> be:
> * Overwritte (--force) (i.e. a conflict scenario)
> * Stop if not-ff (conflict scenario, this patch series)
> * rebase existing onto tracked [not a conflict in terms of initiation]
> * merge existing into tracked [not a conflict in terms of initiation]
> * fast-forward (bring tracked onto existing) [desired]

In short, it sounds to me like that the answer to my question is
"what I do depends too much on what I did on my other machine that
is not even directly connected to this matchine, so there is no way
to formulate it as a concrete workflow---I need to inspect what I
get from the central repository and decide the next step anyway, so
I just want 'git pull' not to do anything".

Among the things that were suggested so far (the 'pull' update that
has been cooking in the 'next' branch, Felipe's tightening to apply
the same logic to 'git pull $there $that' as well as 'git pull', and
being able to set "pull.rebase = fail" and renaming the variable to
something like "pull.integrate = fail"), only the last one seems to
be the solution to your particular case.  The other two would not
help such an ad-hoc (non)workflow very much either way.

Am I reading you correctly?  If so, I sent out the first (or zeroth)
step to add something like that separately.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to