Hi Russell,
On Sat, 16 Feb 2008 00:09:43 + Russell King <[EMAIL PROTECTED]> wrote:
>
> On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote:
> > I will attempt to build the tree between each merge (and a failed build
> > will again cause the offending tree to be dropped). These bu
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote:
> > A third option would be if people add new functions (with no users) in
> > -rc2 or -rc3 timeframes as long as it is part of a fully reviewed
> > patch with users that will use those new features in various kernel
> > development trees
On Wed, Feb 20, 2008 at 10:42:35AM -0500, Theodore Tso wrote:
> On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote:
> > Two things may largely eliminate the need for parallel branches.
> >
> > 1. Do infrastructure changes and whole tree wide refactoring etc. in a
> > compatible manner
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote:
> Two things may largely eliminate the need for parallel branches.
>
> 1. Do infrastructure changes and whole tree wide refactoring etc. in a
> compatible manner with a brief but nonzero transition period.
>
> 2. Insert a second merg
Stephen Rothwell wrote:
> On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
> wrote:
>>
>> I absolutely have no problem with having a "this is the infrastrcture
>> changes that will go into the next release". In fact, I can even
>> *maintain* such a branch.
>>
>> I've
Hi Linus,
On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
> I absolutely have no problem with having a "this is the infrastrcture
> changes that will go into the next release". In fact, I can even
> *maintain* such a branch.
>
> I've not wanted to open up
Frank Seidel wrote:
> Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they
> also really hope - at least i very strongly do - you not only call on us when
> things become a burden, but let us help and assist you right from the start.
I just started a little naive webpage wh
On Sun, 2008-02-17 at 16:25 +1100, Stephen Rothwell wrote:
> Hi James,
>
> On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley <[EMAIL PROTECTED]> wrote:
> >
> > Do you have the tree and build logs available anywhere? I'd like to
> > turn off the merge tree builds when this is able to replace it.
On Tue, 2008-02-12 at 12:24 -0600, James Bottomley wrote:
> Hm ... I think net is a counter example to this. Rebases certainly work
> for them.
That's a matter of opinion.
I'm working on cleaning up the libertas driver as and when I have time,
and the constant rebasing of the git trees effecti
Hi James,
On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley <[EMAIL PROTECTED]> wrote:
>
> Do you have the tree and build logs available anywhere? I'd like to
> turn off the merge tree builds when this is able to replace it.
The tree is at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux
On Fri, 2008-02-15 at 12:02 +1100, Stephen Rothwell wrote:
> Hi Roland,
>
> On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote:
> >
> > For InfiniBand/RDMA, the tree is:
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> > for-next
> >
> > or
On Wed, 13 Feb 2008, Geert Uytterhoeven wrote:
> On Tue, 12 Feb 2008, Greg KH wrote:
> > On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
> > > On Tue, 12 Feb 2008, Greg KH wrote:
> > > > Perhaps you need to switch to using quilt. This is the main reason why
> > > > I use it.
> > >
On Sat, Feb 16, 2008 at 03:42:49AM +0300, Alexey Dobriyan wrote:
> On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote:
> > On Sat, 16 Feb 2008 00:09:43 +
> > Russell King <[EMAIL PROTECTED]> wrote:
> >
> > > For reference, even _I_ don't build test the entire set of ARM defconfigs
On Sat, 16 Feb 2008 00:31:36 +
Russell King <[EMAIL PROTECTED]> wrote:
> > so would a stupid `for i in arch/arm/configs/*' script be sufficient
> > coverage?
>
> It will certainly improve the situation significantly, and pick up
> on some non-ARM problems like (badge4_defconfig, since 2.6.24-g
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote:
> On Sat, 16 Feb 2008 00:09:43 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > For reference, even _I_ don't build test the entire set of ARM defconfigs -
> > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote:
> On Sat, 16 Feb 2008 00:09:43 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > For reference, even _I_ don't build test the entire set of ARM defconfigs -
> > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I
Russell King wrote:
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote:
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
I wonder why I didn't see any of this - I build arm allmodconfig at least
once a week, usually more frequently.
Basically, you don't build any of the PXA p
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote:
> On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
> > I wonder why I didn't see any of this - I build arm allmodconfig at least
> > once a week, usually more frequently.
Basically, you don't build any of the PXA platforms, which
On Sat, 16 Feb 2008 00:09:43 +
Russell King <[EMAIL PROTECTED]> wrote:
> For reference, even _I_ don't build test the entire set of ARM defconfigs -
> at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I
> just build those which are important to myself, hope that the others ar
On Sat, 16 Feb 2008 00:05:59 +0100
Roel Kluin <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> Evolution in nature and changes in code are different because in code junk
> >> and bugs are constantly removed. In biology junk is allowed and may provide
> >> a pool for future development. Linux deve
On Fri, 15 Feb 2008 15:47:24 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
>
> > On Fri, 15 Feb 2008 23:23:08 +
> > Russell King <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> > > > I h
On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote:
> I will attempt to build the tree between each merge (and a failed build
> will again cause the offending tree to be dropped). These builds will be
> necessarily restricted to probably one architecture/config. I will build
> the e
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
> On Fri, 15 Feb 2008 23:23:08 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> > > I have tried, and successfully done this many times in the past. The
> > > kobject change wa
On Fri, 15 Feb 2008 23:23:08 +
Russell King <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> > I have tried, and successfully done this many times in the past. The
> > kobject change was one example: add a new function, migrate all users of
> > a direct
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> I have tried, and successfully done this many times in the past. The
> kobject change was one example: add a new function, migrate all users of
> a direct pointer over to that function, after that work is all done and
> in, change the stru
Alan Cox wrote:
>> Evolution in nature and changes in code are different because in code junk
>> and bugs are constantly removed. In biology junk is allowed and may provide
>> a pool for future development. Linux development is intended and not
>> survival.
>
> I would be interested to see any evi
Linus Torvalds wrote:
>
> On Wed, 13 Feb 2008, Roel Kluin wrote:
>> In nature there is a lot of duplication: several copies of genes can exist
>> and different copies may have a distinct evolution.
>
> This is true of very complex animals, but much less so when looking at
> things like bacteria
On Thu, Feb 14, 2008 at 07:35:03PM +0200, Benny Halevy wrote:
> One idea that I thought about when debating rebase vs. merge (and it's
> far far from being fully baked) is versioned commits. The gist of it
> is that patches are assigned an hash identifier like today when they
> are first committed
On Fri, 15 Feb 2008 04:26:45 EST, Gene Heskett said:
> On Friday 15 February 2008, [EMAIL PROTECTED] wrote:
> >On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
> >> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are
> >> appearing to indicate its not a problem until some distro a
On Friday 15 February 2008, [EMAIL PROTECTED] wrote:
>On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
>> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are
>> appearing to indicate its not a problem until some distro actually ships a
>> kernel with the changes that broke it. Th
On Thu, 14 Feb 2008 12:32:29 PST, Greg KH said:
> How about "weeks". Both Fedora and openSUSE's next release is going to
> be based on 2.6.25, and the first round of -rc1 kernels should be
> showing up in their trees in a few days. So for this instance, I think
> you will be fine :)
a few days =
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing
> to
> indicate its not a problem until some distro actually ships a kernel with the
> changes that broke it. That could be months or even a year plus.
Actually fo
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Feb 2008, Stephen Rothwell wrote:
> >
> > Originally, I assumed the stable branch would be for our "usual" API
> > changes, but it appears we are not having any more of those. :-)
>
> It's not that we should _never_ have them, it's that
Hi Roland,
On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> For InfiniBand/RDMA, the tree is:
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next
>
> or via git protocol:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/i
> The first things I need from the subsystem maintainers (you know who you
> are) are a contact address (a list address is fine) and at least one git
> branch or quilt series that contains all the things you want to see go
> into 2.6.26.
For InfiniBand/RDMA, the tree is:
master.kernel.org
On Thu, Feb 14, 2008 at 01:56:13AM +0100, Roman Zippel wrote:
> Hi,
>
> On Wednesday 13. February 2008, Sam Ravnborg wrote:
>
> > config foo
> > tristate "do you want foo?"
> > depends on USB && BAR
> > module
> > obj-$(CONFIG_FOO) += foo.o
> > foo-y := file1.o file2.o
> >
On Thursday 14 February 2008, Greg KH wrote:
>On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote:
>> On Thursday 14 February 2008, Linus Torvalds wrote:
>> [...]
>>
>> >And this is where "process" really matters. Making sure people don't get
>> >too frustrated about the constant grind.
>>
On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote:
> On Thursday 14 February 2008, Linus Torvalds wrote:
> [...]
> >And this is where "process" really matters. Making sure people don't get
> >too frustrated about the constant grind.
>
> One of the problems caused by this 'grind' is bein
On Thursday 14 February 2008, Linus Torvalds wrote:
[...]
>And this is where "process" really matters. Making sure people don't get
>too frustrated about the constant grind.
One of the problems caused by this 'grind' is being locked out of using 3rd
party closed drivers until the vendor decides i
On Thu, 14 Feb 2008, Stephen Rothwell wrote:
>
> Originally, I assumed the stable branch would be for our "usual" API
> changes, but it appears we are not having any more of those. :-)
It's not that we should _never_ have them, it's that they shouldn't be
"business as usual".
I'm happy with t
On Feb. 13, 2008, 19:52 +0200, "J. Bruce Fields" <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote:
>> So just the fact that the right commit gets blamed when somebody does a
>> "git bisect" is I think a big issue. It's just fundamentally more fair to
>>
Hi Russell,
On Thu, 14 Feb 2008 08:14:05 + Russell King <[EMAIL PROTECTED]> wrote:
>
> On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote:
> > We need to ask Linus to promise that he will pull the stable branch from
> > linux-next first in the merge window. For that to happen, I
On Thu, 14 Feb 2008, Roman Zippel wrote:
> On Wednesday 13. February 2008, Sam Ravnborg wrote:
> > config foo
> > tristate "do you want foo?"
> > depends on USB && BAR
> > module
> > obj-$(CONFIG_FOO) += foo.o
> > foo-y := file1.o file2.o
> > help
> > foo will allo
On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote:
> We need to ask Linus to promise that he will pull the stable branch from
> linux-next first in the merge window. For that to happen, I would expect
> that Linus would also review and sign off (or ack) these commits to the
> linux-
Hi,
On Wednesday 13. February 2008, Sam Ravnborg wrote:
> config foo
> tristate "do you want foo?"
> depends on USB && BAR
> module
> obj-$(CONFIG_FOO) += foo.o
> foo-y := file1.o file2.o
> help
> foo will allow you to explode your PC
I'm more thin
On Wed, Feb 13, 2008 at 01:24:41PM -0700, Ann Davis wrote:
> Frank Seidel wrote:
>>
>> Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they
>> also really hope - at least i very strongly do - you not only call on us when
>> things become a burden, but let us help and assist
Frank Seidel wrote:
Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they
also really hope - at least i very strongly do - you not only call on us when
things become a burden, but let us help and assist you right from the start.
Agreed. I'm happy to do daily builds
> Evolution in nature and changes in code are different because in code junk
> and bugs are constantly removed. In biology junk is allowed and may provide
> a pool for future development. Linux development is intended and not
> survival.
I would be interested to see any evidence (rather than intui
On Wed, 13 Feb 2008, Roel Kluin wrote:
>
> In nature there is a lot of duplication: several copies of genes can exist
> and different copies may have a distinct evolution.
This is true of very complex animals, but much less so when looking at
things like bacteria (and arguably, any current sw
On Wed, Feb 13, 2008 at 05:36:41AM -0500, Theodore Tso wrote:
> On Tue, Feb 12, 2008 at 10:16:53PM -0800, Greg KH wrote:
> > I was amazed at how slow stgit was when I tried it out. I use
> > git-quiltimport a lot and I don't think it's any slower than just using
> > quilt on its own. So I think t
On Tue, Feb 12, 2008 at 09:09:34AM -0800, Linus Torvalds wrote:
>...
> The other is that once somebody says "ok, I *really* need to cause this
> breakage, because there's a major bug or we need it for fundamental reason
> XYZ", then that person should
>
> (a) create a base tree with _just_ that
On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote:
> So just the fact that the right commit gets blamed when somebody does a
> "git bisect" is I think a big issue. It's just fundamentally more fair to
> everybody. And it means that the people who push their work to me can
> really c
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote:
> On Tue, Feb 12, 2008 at 07:46:51PM +, Al Viro wrote:
>...
> > AFAICS, we are in situation when review bandwidth is where the bottleneck
> > is. Not the merge one...
>
> Are there still large numbers of posted patches, not reviewed or
Linus Torvalds wrote:
>
> On Tue, 12 Feb 2008, Greg KH wrote:
>>> That's the point.
>> Not it isn't. To quote you a number of years ago:
>> "Linux is evolution, not intelligent design"
>
> Umm. Have you read a lot of books on evolution?
>
> It doesn't sound like you have.
>
> The fact is,
On Wed, Feb 13, 2008 at 10:06:16AM -0500, John W. Linville wrote:
> On Tue, Feb 12, 2008 at 06:47:30PM -0800, Joel Becker wrote:
> > Make the distinction earlier. With ocfs2 and configfs (we got
> > this scheme from Jeff), we keep the topic branches as "unsafe" - that
> > is, officially rebase
On Tue, Feb 12, 2008 at 06:47:30PM -0800, Joel Becker wrote:
> Make the distinction earlier. With ocfs2 and configfs (we got
> this scheme from Jeff), we keep the topic branches as "unsafe" - that
> is, officially rebaseable . We merge them all into a big "ALL" branch,
> which is also "uns
Stephen Rothwell wrote:
> On Tue, 12 Feb 2008 12:02:08 +1100 Stephen Rothwell wrote:
>> Andrew was looking for someone to run a linux-next tree that just
>> contained the subsystem git and quilt trees for 2.6.x+1 and I (in a
>> moment of madness) volunteered.
>
> I neglected to mention the other b
On Wed, Feb 13, 2008 at 07:06:24AM -0500, Jeff Garzik wrote:
> Russell King wrote:
> >We know that the -mm tree is pretty much useless in terms of code
> >coverage for ARM, and it's getting increasingly unlikely that anything
> >short of a build of all ARM defconfigs will pick up on merge issues -
Russell King wrote:
We know that the -mm tree is pretty much useless in terms of code
coverage for ARM, and it's getting increasingly unlikely that anything
short of a build of all ARM defconfigs will pick up on merge issues -
which is a lot of CPU cycles, and I'm not going to insist its somethin
On Tue, 2008-02-12 at 22:16 -0800, Greg KH wrote:
> Ted's description matches mine (keep quilt tree in git, edit changelog
> entries, rebase on newer kernel versions, etc.) I can go into details
> if needed.
I added some time ago patch history tracking in stgit and you can run
"stg log [--graphic
On Tue, 2008-02-12 at 21:16 -0500, Theodore Tso wrote:
> I've never been very happy with stgit because of past experiences
> which has scarred me when it got get confused and lost my entire patch
> series (this was before git reflogs, so recovery was interesting).
It got much better now :-). W
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote:
> I can run the numbers, but almost every one of those changes has at
> least 2 signed-off-by: on them, so they should all be being reviewed
> properly.
Good joke..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Tue, Feb 12, 2008 at 10:16:53PM -0800, Greg KH wrote:
> I was amazed at how slow stgit was when I tried it out. I use
> git-quiltimport a lot and I don't think it's any slower than just using
> quilt on its own. So I think that the speed issue should be the same.
I like using "guilt" because
On Tue, Feb 12, 2008 at 09:51:52PM +, Alan Cox wrote:
> > We could simply decide that API changes affecting more than one subsystem
> > Must Be Serialized(tm). Explicitly. As in "any such change is posted
>
> Welcome to dreamland. The only way I can get serial changes done is to
> wait month
On Tue, Feb 12, 2008 at 11:19:14AM -0800, Greg KH wrote:
> We usually get this warning today in -mm.
We don't always - and I'd say in terms of ARM it would be extremely rare.
The sysfs API changes at the start of the last merge window is one example
of this.
I had everything nicely prepared in th
>
> 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
>instead have each "thing" have it's own Kconfig.foo or
>Makefile.foo that gets automatically sucked into the main
>directory Makefile or Kconfig using file globs or similar.
So we could do:
config foo
trista
On Tue, 12 Feb 2008, Andrew Morton wrote:
> On Tue, 12 Feb 2008 16:41:49 -0800 (PST)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > Here are some odd-the-cuff
> > suggestions:
> >
> > 1) Make feature-removal-schedule a directory with files in it.
> >Everyone touches that file, creating merg
On Tue, 12 Feb 2008, Greg KH wrote:
> On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
> > On Tue, 12 Feb 2008, Greg KH wrote:
> > > Perhaps you need to switch to using quilt. This is the main reason why
> > > I use it.
> >
> > Btw, on that note: if some quilt user can send an "ann
On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 12 Feb 2008, Greg KH wrote:
> >
> > Perhaps you need to switch to using quilt. This is the main reason why
> > I use it.
>
> Btw, on that note: if some quilt user can send an "annotated history file"
> of their quil
On Tue, 12 Feb 2008, J. Bruce Fields wrote:
> > So as a result, some *random* commit that was actually fine on its own has
> > now become a bug, just because it was re-written.
>
> If there was a "fundamental thing that didn't cause a conflict", then
> the two trees in question probably didn'
On Tue, 12 Feb 2008, Linus Torvalds wrote:
> Of course, if you didn't even want to save the old branch, just skip the
> first step. If you have reflogs enabled (and git does that by default in
> any half-way recent version), you can always find it again, even without
> having to do "git fsck --
On Tue, 12 Feb 2008, Linus Torvalds wrote:
> So let's say that you have a remote branch that you track that goes
> rebasing (let's call it "origin/pu" to match the real-life git behaviour),
> then you should literally be able to do
>
> old=$(git rev-parse origin/pu) &&
> git fetch
After glancing at some of this thread its clear to me what Stephen's
real goal is:
1. collect kernel trees (or underpants)
2. ?
3. profit
http://en.wikipedia.org/wiki/Underpants_Gnomes
- k
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
On Tue, Feb 12, 2008 at 05:20:51PM -0800, David Miller wrote:
> From: Linus Torvalds <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST)
>
> > gitk --merge
> ...
> > This is something where I actually think git could and should do better:
> > git has the capability to act as mo
On Tue, Feb 12, 2008 at 05:31:10PM -0800, Linus Torvalds wrote:
> The importance of merging (rather, not screwing up history in general)
> becomes really obvious when things go tits-up. Then they go tits-up
> *without* screwing up the history of the trees that were hopefully tested
> individuall
On Tue, Feb 12, 2008 at 09:00:16PM -0600, James Bottomley wrote:
> On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote:
> >
> > On Tue, 12 Feb 2008, James Bottomley wrote:
> > >
> > > Yes, this is exactly the feature I'm looking for. It would allow the
> > > downstream users of a rebased tre
On Tue, 2008-02-12 at 19:31 -0800, Linus Torvalds wrote:
>
> On Tue, 12 Feb 2008, James Bottomley wrote:
> >
> > Right at the moment, I maintain a and a -base and
> > simply cherry pick the commits between the two to do the right thing
> > when I know my volatile base has changed. It would be
On Tue, 12 Feb 2008, Linus Torvalds wrote:
>
> git rebase --onto $new $old
..and in case it wasn't clear - this is just a general way of saying "move
the commits on this branch since $old to be based on top of $new" instead.
You can pick out those old/new commit ID's using gitk or whatev
On Tue, 12 Feb 2008, James Bottomley wrote:
>
> Right at the moment, I maintain a and a -base and
> simply cherry pick the commits between the two to do the right thing
> when I know my volatile base has changed. It would be very helpful to
> have a version of rebase that new my base had been
On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote:
>
> On Tue, 12 Feb 2008, James Bottomley wrote:
> >
> > Yes, this is exactly the feature I'm looking for. It would allow the
> > downstream users of a rebased tree to rebase themselves correctly.
> >
> > All the information about the reba
On Tue, Feb 12, 2008 at 06:20:12PM -0800, David Miller wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 18:06:13 -0800
>
> > So perhaps a better workflow would be keep the linux-next trees all
> > messy, and then each developer can consolidate, rebase, join and
> > drop th
On Tue, 12 Feb 2008, James Bottomley wrote:
>
> Yes, this is exactly the feature I'm looking for. It would allow the
> downstream users of a rebased tree to rebase themselves correctly.
>
> All the information about the rebase is in the reflog ... it can't be
> too difficult to pass it through
On Tue, 2008-02-12 at 17:20 -0800, David Miller wrote:
> What would be really cool is if you could do the rebase thing, push
> that to a remote tree you were already pushing into and others could
> pull from that and all the right things happen.
>
> A rebase is just a series of events, and those c
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 18:06:13 -0800
> So perhaps a better workflow would be keep the linux-next trees all
> messy, and then each developer can consolidate, rebase, join and
> drop things prior to sending their individual trees to Linus.
We could do that,
On Tue, 12 Feb 2008, Andrew Morton wrote:
>
> So it would not be efficient for David to do all this queue-cleaning
> *prior* to putting the tree into linux-next, because more stuff will pop up
> anyway.
Well, what others have done is to have special "temporary branches".
This is what git itsel
On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
> On Tue, 12 Feb 2008, Greg KH wrote:
> >
> > Perhaps you need to switch to using quilt. This is the main reason why
> > I use it.
>
> Btw, on that note: if some quilt user can send an "annotated history file"
> of their quilt usag
On Tue, 12 Feb 2008 17:57:19 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> - and you actually can help fix your issues by doing some simple things
>*before* pushing out, rather than push out immediately. IOW, do your
>whitespace sanity fixes, your compile checks etc early, an
On Tue, 12 Feb 2008, David Miller wrote:
>
> Now how do I remove a bogus commit for a tree that I've already pushed
> out and published for other people, without any record of it appearing
> in the GIT tree any more?
So, the answer is: if others have actually pulled, it's simply not
possible.
On Tue, 12 Feb 2008 17:16:03 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 16:37:42 -0800
>
> > Well there's a case in point. rcupdate.h is not a part of networking, and
> > it is random tree-wandering like this which cause
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 17:41:19 -0800 (PST)
> Trust me, you don't know how good you have it.
I know, preserving history is valuable.
I'll take up the various suggestions and try working
a little differently this time around. We'll see
how well it works.
On Tue, 12 Feb 2008, David Miller wrote:
>
> But as soon as I've applied any patches to my tree I've "pushed out".
> So this scheme doesn't work for me. The first thing I do when I have
> changes to apply is clone a tree locally and on master.kernel.org,
> then I apply that first patch locally
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 17:31:10 -0800 (PST)
> You don't see the problems as much, because you merge probably only
> about a tenth of the volume I merge, and you can keep track of the
> subsystem more.
Good point.
Now how do I remove a bogus commit for a t
On Tue, 12 Feb 2008, David Miller wrote:
>
> > Put another way: think of the absolute *chaos* that would happen if I were
> > to rebase instead of just merging. Every time I pull from you I'd
> > invalidate your whole tree, and you'd have to re-generate. It gets
> > unmaintainable very quickl
On Tue, Feb 12, 2008 at 04:59:23PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 13 Feb 2008, Al Viro wrote:
>
> > On Tue, Feb 12, 2008 at 07:16:50PM -0500, J. Bruce Fields wrote:
> > > > Ahem... Use of git-cherry-pick preserves commit information just fine.
> > >
> > > Not by default, at least (
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:53:50 -0800 (PST)
> The fact is, that "outlying code" is where we have all the bulk of the
> code, and it's also where we have all those developers who aren't on the
> "inside track". So we should help the outliers, not the core
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:49:46 -0800 (PST)
> Btw, on that note: if some quilt user can send an "annotated history file"
> of their quilt usage, it's something that git really can do, and I'll see
> if I can merge (or rather, coax Junio to merge) the rele
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:47:26 -0800
> My usual way of fixing these things when they pop up is to just move
> the offending addition to some random position other than
> end-of-list. I must have done this hundreds of times and as yet I
> don't think anyone
On Tue, 12 Feb 2008 12:02:08 +1100 Stephen Rothwell wrote:
> Hi all,
>
> Andrew was looking for someone to run a linux-next tree that just
> contained the subsystem git and quilt trees for 2.6.x+1 and I (in a
> moment of madness) volunteered. So, this is to announce the creating of
> such a tree
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST)
> gitk --merge
...
> This is something where I actually think git could and should do better:
> git has the capability to act as more of a "quilt replacement", but
> because it wasn't part of the original
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:37:42 -0800
> Well there's a case in point. rcupdate.h is not a part of networking, and
> it is random tree-wandering like this which causes me problems and which
> will cause Stephen problems.
>
> Now, I don't know which tree "ow
1 - 100 of 204 matches
Mail list logo
