hello,
Why don't use a -mm git tree? Maybe it was time for it.
With a -mm git tree, we can help -mm test much earlier and quicker,
and no more need of the mm-commits ML.
Also an option, to use git, and still gernerate broken-out from git.
--
Coywolf Qi Hunt
Coywolf Qi Hunt wrote:
> hello,
>
> Why don't use a -mm git tree? Maybe it was time for it.
> With a -mm git tree, we can help -mm test much earlier and quicker,
A -mm git tree would be nice.
> and no more need of the mm-commits ML.
Strongly disagree.
> Also an option, to use git, and still gernerate broken-out from git.
AFAICT from akpm's workflow, it would be far easier to generate a git
tree from his pile of patches, than the other way around.
Jeff
Coywolf Qi Hunt <[email protected]> wrote:
>
> Why don't use a -mm git tree?
>
Because everthing would take me 100x longer?
I'm looking into generating a pullable git tree for each -mm. Just as a
convenience for people who can't type "ftp".
That'll just be a dump of the whole -mm lineup into git. I don't know how
workable it'll be - we'll see.
On Tue, Jan 10, 2006 at 10:44:51PM -0800, Andrew Morton wrote:
> Coywolf Qi Hunt <[email protected]> wrote:
> >
> > Why don't use a -mm git tree?
> >
>
> Because everthing would take me 100x longer?
Really? So does Linus?
>
> I'm looking into generating a pullable git tree for each -mm. Just as a
> convenience for people who can't type "ftp".
That doesn't help much if it's only for each -mm.
If you make git commits for each each patch merged in, then
we can always run the `current' -mm git tree.
Test the -mm patches, not leave them sleeping for most of the time.
>
> That'll just be a dump of the whole -mm lineup into git. I don't know how
> workable it'll be - we'll see.
>
--
Coywolf Qi Hunt
Coywolf Qi Hunt <[email protected]> wrote:
>
> On Tue, Jan 10, 2006 at 10:44:51PM -0800, Andrew Morton wrote:
> > Coywolf Qi Hunt <[email protected]> wrote:
> > >
> > > Why don't use a -mm git tree?
> > >
> >
> > Because everthing would take me 100x longer?
>
> Really? So does Linus?
>
Linus does a totally different thing from me.
He reverts about one patch a month. I drop tens a day.
He never _alters_ patches. 2.6.15-mm1 had about 200 patches which modify
earlier patches and which get rolled up into the patch-which-they-modify
before going upstream.
He never alters the order of patches.
etc.
> >
> > I'm looking into generating a pullable git tree for each -mm. Just as a
> > convenience for people who can't type "ftp".
>
> That doesn't help much if it's only for each -mm.
> If you make git commits for each each patch merged in, then
> we can always run the `current' -mm git tree.
Ah. If you're suggesting that the -mm git tree have _patches_ under git,
and the way of grabbing the -mm tree is to pull everything and to then
apply all the patches under the patches/ directory then yeah, that would
work.
But my tree at any random point in time is a random piece of
doesn't-even-compile-let-alone-run crap, believe me. Often not all the
patches even apply. I don't think there's much point in exposing people to
something like that.
On 1/11/06, Andrew Morton <[email protected]> wrote:
> Coywolf Qi Hunt <[email protected]> wrote:
> >
> > On Tue, Jan 10, 2006 at 10:44:51PM -0800, Andrew Morton wrote:
> > > Coywolf Qi Hunt <[email protected]> wrote:
> > > >
> > > > Why don't use a -mm git tree?
> > > >
> > >
> > > Because everthing would take me 100x longer?
> >
> > Really? So does Linus?
> >
>
> Linus does a totally different thing from me.
>
> He reverts about one patch a month. I drop tens a day.
>
> He never _alters_ patches. 2.6.15-mm1 had about 200 patches which modify
> earlier patches and which get rolled up into the patch-which-they-modify
> before going upstream.
>
> He never alters the order of patches.
>
> etc.
>
> > >
> > > I'm looking into generating a pullable git tree for each -mm. Just as a
> > > convenience for people who can't type "ftp".
> >
> > That doesn't help much if it's only for each -mm.
> > If you make git commits for each each patch merged in, then
> > we can always run the `current' -mm git tree.
>
> Ah. If you're suggesting that the -mm git tree have _patches_ under git,
> and the way of grabbing the -mm tree is to pull everything and to then
> apply all the patches under the patches/ directory then yeah, that would
> work.
>
> But my tree at any random point in time is a random piece of
> doesn't-even-compile-let-alone-run crap, believe me. Often not all the
> patches even apply. I don't think there's much point in exposing people to
> something like that.
Andew,
did you consider Stacked GIT as an alternative to quilt ?
--
Paolo
Paolo Ciarrocchi <[email protected]> wrote:
>
> > Ah. If you're suggesting that the -mm git tree have _patches_ under git,
> > and the way of grabbing the -mm tree is to pull everything and to then
> > apply all the patches under the patches/ directory then yeah, that would
> > work.
> >
> > But my tree at any random point in time is a random piece of
> > doesn't-even-compile-let-alone-run crap, believe me. Often not all the
> > patches even apply. I don't think there's much point in exposing people to
> > something like that.
>
> Andew,
> did you consider Stacked GIT as an alternative to quilt ?
I looked at the web page - stgit seems to be broken-out patches
revision-controlled under git. I don't think that affects any of the
considerations I've outlined?
On Wed, Jan 11, 2006 at 09:11:25AM -0800, Andrew Morton wrote:
> Paolo Ciarrocchi <[email protected]> wrote:
> > did you consider Stacked GIT as an alternative to quilt ?
>
> I looked at the web page - stgit seems to be broken-out patches
> revision-controlled under git.
It doesn't really attempt to do revision control on the patches.
--b.