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