Branches to patches

[Yaroslav Halchenko]

> Out of curiosity (and this is one of the places where I'm just a Git
> newbie), why would I ever want to rebase and not merge?  I'm currently
> merging and it works great.  I'm not sure what the advantage of
> rebasing instead would be.
there are many use cases (there are some in git rebase --help), where
rebase is the only option (like moving branch X which is based on Y, to
be based on some other branch Z -- for instance feature X is apparently
not to be distributed in public domain, thus should be based on branch Y
which is for 'private use only', or vise versa -- and for that branch
has to be rebased, and if smth was merged into it from X, then
rebasing onto Y would bring X into it).

But in this case for feature branches imho a branch without multiple
merges from upstream branch looks much cleaner and it is easy to rebase
it if needed against any ref in repository (e.g. you need to apply that
branch to test if it solves issues in the maintained version of package
within etch) -- another option would be cherry picking but rebasing
would be cleaner imho and easier.

Am I missing some other critical use cases?

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik