Re: [PATCH] Give better 'pull' advice when pushing non-ff updates to current branch

Christopher Tiwald [off-list ref] writes:

Suppose a user configured a local branch to track an upstream branch by
a different name or didn't set an upstream branch at all. In these
cases, issuing 'git pull' without specifying a remote repository or
refspec can be dangerous. In the first case, 'git pull --rebase' could
rewrite published history. In the second, 'git pull' without argument
will fail.

The latter case of stopping without causing damage is hardly dangerous,
so I'll ignore that for now, but I am not sure what you mean by the
former.  A "devel" branch has "master" from "origin" (or whatever
branch.devel.remote is set) as its upstream (i.e. "devel" and "master"
are different strings).  "git pull" will then fetch "master" from the
other side, and either merge that into "devel" or rebuild "devel" on top
of it if you gave "--rebase".

But if you used "master", not "devel", as the name of your local branch,
I do not see anything changes.  You may have published the tip of
"master" to a third repository before doing "pull --rebase", and you may
be rebasing the history leading to that commit.  Even if there is no
third repository, your "master" may be pushed to some other branch of
"origin", so the story is the same.  If your counter-argument is "but
but but I will never ever push my 'master' to names other than 'master'
at 'origin'", then in your original settings where your local branch is
called "devel", you will never ever push you 'devel' to branches other
than 'master' at 'origin', exactly because its upstream is set to
'master'.

So what makes it dangerous is the use of "--rebase", if anything, isn't
it?  It does not seem to have much to do with how the local branches are
named.