On Mon, 2006-09-11 at 19:03 -0700, Tom Rini wrote: > On Mon, Sep 11, 2006 at 06:35:59PM -0700, Piet Delaney wrote: > > On Sat, 2006-09-09 at 12:28 -0700, Tom Rini wrote: > > > On Sat, Sep 09, 2006 at 10:52:18PM +0400, Sergei Shtylyov wrote: > > > > > > > >to fix some of these issues happily reviewed :) > > > > > > > > Erm, it's either you created the trees too soon, or we (most > > > > probably) > > > > dalayed with updating the patches too much. The thing is, I have > > > > reworked > > > > TX49 driver and also renamed it following the recent, suffixing scheme > > > > -- I > > > > know git can handle renames but patch(1) cannot. How should we handle > > > > this? > > > > > > OK, I'll try and follow up to one of the other emails so people have > > > less of an excuse for not seeing things, but.. > > > > > > My preference for getting changes to KGDB is still with plain old GNU > > > patches. Generating these is really up to the preference of the > > > developer. If you like using git to track your own work, grab one of > > > the regular git versions of the tree, work, export and email. If you > > > like using stacked git, grab the stacked git tree and work on top of > > > what I've done already, export and mail. Sound sane? > > > > I haven't used git enough to be sure but assuming it's like bit keeper, > > I think it's easiest to push and pull git work spaces. I get the > > impression that other parts of the kernel are being pushd and pulled > > between developers on vger. Might be maximally productive to do the > > same with the kgdb git repositories. Something like: > > The problem is that we're using stacked git, which doesn't yet actually > support remote repositories. So regular patches are easier at this > point.
When you said "stacked git" I assumed you were referring to a set of git
repositories, matched for the various kgdb patches, with each being
a parent and child of the other git repositories:
linus kernel
|
v
mm-patch <----> Andrews Patches
|
v
kgdb-core-lite <----> kgdb patch
|
v
kgdb-eth <----> kgdb patch
|
v
kgdb-core <----> kgdb patch
|
v
kgdb-i386 <---> kgdb patch
|
v
kgdb-master
|
v
kgdb-developer
So once kgdb-developer was accepted it could be pushd up the
the appropriate level. Andrew has a broken out patch mechanism
but I haven't noticed that preventing him from pulling git
repositories. I notices git having a patch facility but I
haven't tried that yet.
The vger developers seems to have a pretty smooth development
environment set up; I suspect it would be optimal for use to use
the same paradigm in the not to distant future. I was thinking
that a bitkeeper hierarchy was better than what we are doing;
but I think your git-vger idea is/was great and we should build
on that.
I just did a Google on "stacked git" and NOW see that you were
likely referring to this Python StGit stuff:
http://www.procode.org/stgit/
http://lwn.net/Articles/187116/
Looks like I need to do some homework....
-piet
>
--
Piet Delaney Phone: (408) 200-5256
Blue Lane Technologies Fax: (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014 Email: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
