Re: git rebase: yet another newbie quest.

[Sergey Organov <sorganov@gmail.com>]

Theodore Ts'o <tytso@mit.edu> 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.