Re: git rebase: yet another newbie quest.

[Theodore Ts'o <tytso@mit.edu>]

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