Re: [Adeos-main] Re: [RFC] git workflow

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

Wolfgang Denk wrote:
> In message <4587F9CE.3060403@domain.hid> you wrote:
>> Once there is a public tree with 2.6.20-rc1 + ipipe + -rc2, you cannot
>> simply turn that tree into 2.6.20-rc1 + -rc2 + ipipe. The order of
>> patches is practically frozen once published. In your private tree you
>> are, of course, free to do this and then extract some patch to post
>> upstream.
> 
> I'm not sure if it really makes sense to maintain this as a git
> repository - that would be OK if we wanted to provide a pre-patched
> tree to the public (which might be a good thing to have, btw.).

This is one of my motivations to push git forward. Having
2.6.20-rcX+ipipe already available for download and testing may help to
follow the kernel development on the bleeding edge more closely.

The other aspect is that when you merge the kernel patches into a
working ipipe tree and you get a conflict, you also directly obtain
information about what change caused it and maybe what the background of
that patch was. That's at least my theory which still needs to be proven
in practice.

> 
> As long as we're basicly trying to manage the patches in a way that
> integrates well with git we should do exactly that: manage the
> patches under git, i. e. use stgit (see http://www.procode.org/stgit/).

I heard about it before, but I still have to take a closer look. Does
this generate also some kind of publishable git tree with history for
the managed patches? One problem with a stack might be that we loose
information about ipipe changes themselves. My idea is that some
modification to the ipipe core stored as commit in the reference tree
could directly be pulled by other arch maintainers.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]