> 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.
Thomas Koch, http://www.koch.ro
vcs-pkg-discuss mailing list