Theodore Ts'o <tytso@xxxxxxx> writes: > 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. You got it somewhat wrong. I intended 'topic' to track 'master', not '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". I thought it's rather common for one local branch to track another in the git world. At least all machinery is there, and I don't see how tracking local branch is different from tracking remote branch, fundamentally. > 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. Yeah, and I simply wanted to shorten it to "git checkout topic; git rebase", by making git remember I want to rebase w.r.t. 'master' by default. > 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? As far as I can see, what I did is almost exactly what you do, except I didn't want to tell "master" every time I want to rebase 'topic' branch. Configuring tracking branch and saying just "git rebase" when you are on the branch seems to be logical, and there doesn't seem to be anything wrong with it (except strange git default behavior), or does it? > 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. That's good advice indeed, but it's unrelated to the issue at hand, as you still rebase, sooner or later. -- Sergey. -- 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
