rethinking patch management with GIT / topgit

Manoj Srivastava srivasta at acm.org
Fri Mar 26 14:16:23 UTC 2010


On Wed, Mar 24 2010, Thomas Koch wrote:

> 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.

        Hmm. That would mean a lot more work if you are carrying long
 term features or modification to upstream to better fit the
 Distribution policy. I don't  cut a new branch fr each upstream; I have
 an integration branch that carries in it history of previous integration
 changes (conflict resolution for long term fixes/features),  and
 cutting a new branch from upstream would have me recreating all that
 work.

        I have heard people say that distributions should not carry
 feature branches or long term fixes, but push it upstream; but  in a
 non ideal world some upstreams do not respond as quickly as one wants,
 and secondly, a user obsession requires that users get desirable
 features, even if upstream is tardy or does not see the light, and thus
 feature branches might linger.

        manoj
-- 
Behind every great man, there is a woman -- urging him on. Harry Mudd,
"I, Mudd", stardate 4513.3
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C



More information about the vcs-pkg-discuss mailing list