rethinking patch management with GIT / topgit

[Thomas Koch]

Hi Enrico,

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.
While I don't agree with your prefered workflow, I think it's a very nice 
attribute of my proposal, that both workflows could be implemented with it. We 
could use the same tool and still have different workflows.

Best regards, 

Thomas Koch, http://www.koch.ro