On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote: > > except that I wanted to configure upstream as well for the topic-branch, > that looks like pretty legit desire. If I didn't, I'd need to specify > upstream explicitly in the "git rebase", and I'd not notice the problem > at all, as the actual problem is that "git rebase" and "git rebase > <upstream>" work differently! Right, so I never do that. I have master track origin/master, where it automagically does the right thing, but I'm not even sure I can articulate what it *means* to have topic also track origin/master. I just don't have a mental model for it, and so it falls in the category of "it's too complicated for my simple brain to figure out". So I just do "git rebase master", and I would never even *consider* doing a "git pull --rebase". I'll do a "git fetch", and then look at what just landed, and and then checkout master, update it to origin/master, and then run the regression tests to make sure what just came in from outside actually was *sane*, and only then would I do a "git checkout topic; git rebase master", and then re-run the regression tests a third time. Otherwise, how would I know whether the regression came in from origin/master, or from my topic branch, or from the result of rebasing the topic branch on top of origin/master? And of course, this goes back to my observation that I don't rebase my topic branchs all that often anyway, just because the moment you do the rebase, you've invalidated all of the testing that you've done to date. In fact, some upstreams will tell explicitly tell you to never rebase a topic branch before you ask them to pull it in, unless you need to handle some non-trivial merge conflict. Cheers, - Ted -- 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