Re: git rebase: yet another newbie quest.

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

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.

> Please also notice that I didn't pull immediately after I've re-arranged
> my branches, and this fact only made it more difficult to find and
> isolate the problem.

It's also the case that I rarely will do a "git rebase" without taking
a look at the branches to make sure it will do what I expect.  I'll do
that using either "gitk" or "git lgt", where git lgt is defined in my
.gitconfig as:

[alias]
	lgt = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit

And typically what I will do is something like this:

gitk -20 master origin/master topic

-or-

git lgt -20 master origin/master topic

The "git lgt" command is very handy when I want to see how the
branches are arranged, and I'm logged remotely over ssh/tmux or some
such, so gitk isn't really available to me.

Cheers,

						- Ted