Wolfgang Denk wrote: > Dear Jan, > > in message <[EMAIL PROTECTED]> you wrote: >> 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. > > Agreed. > >> 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. > > THis will work, but if you go this route you will sonn have the git > repo only, as it will become more and more difficult to extract the > ipipe patches which you need anyway. > > That's why I recommend to use stgit to maintain the ipipe patches. So > you have a clearly defined flow of information. > >> 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? ... > > Yes, it does. > >> ... One problem with a stack might be that we loose >> information about ipipe changes themselves. ... > > No, that's not true, as the patches itself are managed under git, so > you have the full power of git for the patch history, too. > > This will be much more powerful than the other approach - if you > maintain a patched tree under git, it will be pretty difficult to > find out which changes make up the ipipe patch, and which are other > stuff.
Might be true when you browse the log. But I guess some magic can be
applied in that case as well, or we put a unique tag into the commit
name ("[IPIPE] optimise IRQ fast-path").
>
>> ... 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.
>
> That sounds as if you are planning to use stgit already, without
> knowing it yet :-)
Well, I may still oversee something, but after having a first look and
also reading the tutorial it seems to me that there is actually no magic
behind stgit. Means, it just works with the same mechanism plain git
does. When you "stg pull", you remove your patches from the stack, apply
the upstream changes, and then add your patches again - git rebase. So
when you want to publish your stgit tree, you still need to merge your
patches (stg commit). And at that moment you set the whole tree ordering
in stone. Back to #1.
stgit is surely useful for managing private trees, but I don't see how
it can help us when we want to publish our working trees.
Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
