"Philip Oakley" <philipoakley@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html