Re: nicer frontend to get rebased tree?

[Jakub Narebski <jnareb@gmail.com>]

Andi Kleen wrote:
> Jakub Narębski wrote:
> > 
> > BTW. it is stated countless time in documentation that published
> > history should be not rebased, barring some extenuating
> > circumstances 
> 
> Yes and people countless times ignore that recommendation and do 
> it anyways (for good reasons).  And then other users 
> have to deal with these rebased trees somehow.

If you are thinking about 'linux-next', it is exception rather than
the rule.

Besides, Git is feature rich and allows many different workflows, so
you should _always_ read the Development/Contributing document for
specific project, if it exists.  (See also explanation below on 
different workflows). 

> Anyways it is all solvable but right now ill supported
> in standard commands and the documentation does not really
> cover it. I was just asking (mostly for others to avoid
> going through the same pain as me) for that to be improved
> so that git becomes easier to use.
> 
> Sadly you guys don't even seem to want to recognize there
> is a problem :-( 

First, there isn't just _one_ way to deal with non fast-forward 
(rebased) branch; there are many possible workflow wrt rebasing.

There can be something like 'pu' (proposed updates) branch in git 
repository, which is basically read-only, rebuild from scratch merging 
branch gathering topic branches which are not ready yet for 'next'
(for development branch), like work in progress and the like.  It is 
here to be able to view/examine those topic branches, without crowding 
public branch namespace.  In short: it is only to view.
Workflow:
  $ git fetch origin   OR   git remote update

Then there is something like 'linux-next' tree, which is also rebuild 
from scratch, and as far as I understand serves as gathering point for 
different patches being prepared to enter Linux, and to resolve 
conflicts early.  It is, if I understand correctly, to check if it 
compiles and doesn't have bugs, and to test merging your work; _not_
to base your own work on.
Workflow:
  $ git fetch origin   OR   git remote update
  $ git checkout origin/master  # detaches HEAD / not on any branch

Finally (or not: perhaps there are yet different workflows involving
history rewriting) there are projects which use rebase based workflow.
The information about it should be on project homepage (or wiki).
Workflow:
  $ git pull --rebase  # or configure it: branch.autosetuprebase etc.


Second, this is open source. If you feel that documentation needs 
improvement, now that you have all this information, you can simply 
send patch either to manpages, or to Git User's Manual.  Trolling won't 
work ;-P
-- 
Jakub Narebski
Poland