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 -- 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