rethinking patch management with GIT / topgit

[Enrico Weigelt]

Petr Baudis wrote:

>   The reason to ponder all this is precisely to _avoid_ rebasing,
> which brings many problems - it's PITA to maintain rebasing branches
> in a distributed manner, there is no public history record of the
> rebases, etc. The alternate solutions try to maintain custom
> modifications in a manner that is

What exactly is the problem w/ rebasing ?

Once a new upstream is out, somebody simply forks a new branch from
the last one, rebases it to the new upstream and publishes it when done.
We actually dont rebase _existing_ (already published) branches, but
add new ones which just happen to be created via rebase (instead of
cherry-picking or appling patchsets manually).

>   under the presumption that these are desirable properties. With simple
> "maintenance-branches" approach, you have to rebase and abandon (i), or
> merge repeatedly and give up (ii).

No. Each upstream release brings a new distro branch. Trivial.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info at metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------