Re: [PATCH 3/5] pull: handle conflicting rebase/merge options via last option wins

>
> Elijah Newren <newren@gmail.com> writes:
>
> > I thought this was the biggest hole in my proposal: there is both a
> > git merge --no-ff and a git rebase --no-ff, and they avoid
> > fast-forwards in different ways with different results.
>
> When you say "git rebase --no-ff upstream", you are telling the
> machinery that even if your current work is direct descendant of the
> upstream, you want your commits freshly rebuilt.  But in the context
> of "pull", you being descendant of the other side is called "already
> up to date", not even "fast forward" (the ancestry relationship
> between you and the other side is the other way around).