Theodore Ts'o <tytso@xxxxxxx> writes: > On Mon, Sep 08, 2014 at 05:52:44PM +0400, Sergey Organov wrote: >> >> I didn't intend to make topic branch from the very beginning, and >> already made a commit or two on the remote tracking branch bofore I >> realized I'd better use topic branch. It'd create no problem as far as I >> can see, provided vanilla "git rebase" has "sane" defaults. That said, >> I've already been once pointed to by Junio that my definition of "sane" >> doesn't take into account workflows of others, so now I try to be >> carefull calling vanilla "git rebase" names. > > Right, so what I typically in that situation is the following: > > <on the master branch> > <hack hack hack> > git commit > <hack hack hack> > git commit > <oops, I should have created a topic branch> > git checkout -b topic-branch > git branch -f master origin/msater > > This resets the master branch to only have what is in the upstream > commit. But that's *exactly* what lead me to the problem! Here is relevant part of my script: git checkout -b topic git branch --force master origin_master git branch -u master 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! -- Sergey. P.S. Nice 'lgt' alias, BTW. I simply use: $ git help hist git hist' is aliased to `log --oneline --graph --decorate' stolen somewhere. -- 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