Re: git rebase: yet another newbie quest.

From: Theodore Ts'o <tytso@mit.edu>
Date: Sep 8, 2014, 17:32 UTC
Message-ID: <20140908173251.GA24855@thunk.org>
In-Reply-To: <87fvg23yhx.fsf@osv.gnss.ru>

On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote:

Show 6 quoted lines

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