Re: [gtk-gnutella-devel] GIT transition, please verify current conversion to git

[Hauke L. <ha...@pa...>]

On Tuesday 06 September 2011, Bill Pringlemeir wrote:
> On  4 Sep 2011, ha...@pa... wrote:
>> Rebasing means automatically rewriting the latest part of your
>> commit history so that it is based on a different parent commit.
>> This is necessary to avoid conflicts when you pull from an
>> integrator who changed your commits, and it is also a nice tool to
>> make your history look cleaner before you share it. But is has not
>> that much to do with Raphael's particular problem.
> 
> Are you sure?  If he is working on DOVE changes (say a branch),
> wouldn't he want to rebase with the 'master' so he could see how the
> DOVE changes are integrating with whatever was pushed to the
> 'master'?

Not necessarily. To integrate new changes from the master branch into 
his half-done dove branch, he can simply use good old "git merge" 
instead of "git rebase". The resulting code would be the same, but the 
resulting history graph would map reality better.

You linked to an interesting document in your last mail:
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
It says there:

> There are two main tools that can be used to include changes from one
> branch on another: git-merge(1) and git-cherry-pick(1). Merges have
> many advantages, so we try to solve as many problems as possible with
> merges alone. Cherry-picking is still occasionally useful;

While reading this, be aware that a rebase (without its optional 
features like squashing) is equivalent to a series of cherry-picks.

> I think this is something that will change his 'sandbox' concept.

I hope so. What I read between Raphael's lines (I may be wrong) sounded 
like he merged his ready-to-release branches by hand, which would be 
error-prone and a pain in the rear.

> Also, his 'DOVE' branch wouldn't have to be pushed/pulled
> to the origin (master remote server).

Sure, that's the whole point of decentalized branches.

> I am not a git guru, so maybe something is wrong.

In principal, there was nothing wrong with your proposal. Raphael could 
indeed use rebase to keep the underlying code base of his feature 
branches up-to-date. But I think that: a) one should prefer merge over 
rebase to do that, b) repeatedly synching feature branches with master 
is in most cases not necessary at all, and c) this whole discussion 
misses Raphael's original question about using multiple _directories_ 
for his multiple branches (which complicates his workflow at the command 
level but is otherwise equivalent).

Bye,
Hauke

PS, by the way:

>  git branch master # switch back to master.

You switch branches with "git checkout", not "git branch".