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

[Christopher Tiwald <christiwald@gmail.com>]

On Mon, Apr 23, 2012 at 07:17:25PM -0700, Junio C Hamano wrote:
> 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.

After thinking about this argument, there might be a deeper problem with
my reasoning. Take the workflow you describe. In the "devel tracks to origin
master" workflow, this patch would advise 'git pull <repository> <refspec>'.
The advice misses the point of setting the upstream branch. Worse, the
advice is broken if the user issues 'git pull origin devel' and no 'devel'
branch exists on origin or the 'devel' branch is simply out of date (as
might occur if the user pushes between a personal remote clone of a
shared repo and the shared repo itself with different frequency).

Maybe the solution here is to ditch the $dest_ref and $dest_remote
matching entirely and just touch the one case I _know_ the advice could
do better: git should advise 'git pull <repo> <refspec>' or something
like "consider setting an upstream branch and pulling before pushing
again" when branch->merge doesn't exist at all. I like the former
because it's simpler as an end user and doesn't require enforcing a
setting he or she may not understand.

I think that might be the way to go. I approached this from a specific
workflow assumption. In retrospect, I can't divine the motivation of
merge configurations well enough to avoid bad advice.

--
Christopher Tiwald