On Tue, Aug 18, 2009 at 02:57:48PM -0700, Luis R. Rodriguez wrote: > On Tue, Aug 18, 2009 at 02:45:00PM -0700, Pavel Roskin wrote: > > On Tue, 2009-08-18 at 14:24 -0700, Luis R. Rodriguez wrote: > > > > > > Anyway, why is it better for bisecting? > > > > > > Because to help developers not have to do: > > > > > > git branch -m poo > > > git checkout -b master origin/master > > > # Then apply patches manually > > > > > > Instead of the better rebasing: > > > > > > git branch -m save-my-stuff > > > git checkout -b master origin/master > > > git checkout save-my-stuff > > > git rebase master > > > > I use STGit, so perhaps I miss all that fun. I have never had any > > trouble tracking wireless-testing while keeping my patches. > > Oh this was a long time ago, pre ath5k I think. > > > > john reverts his patches on wireless-testing before rebasing to Linus' > > > tree. There may be some other added benefit other than helping us > > > rebase cleanly, not sure. But I do remember before that I never was > > > able to rebase my patches, and now rebasing works quite nicely. > > > > You mean it's better to track wireless-next-2.6 for those of us trying > > to stay on top of the wireless development? > > No, not at all, I meant wireless-next-2.6 is best for bisecting. > > wireless-testing is indeed the place to look at for development. > > > I must have missed the > > memo. > > I don't think we ever really publized this much, because technically > the reverting won't happen unless John rebases and typically between > rebases to a next RC kernel you *could* technically bisect an issue. > But not all the times. > > > Indeed, wireless-next-2.6 has a couple of commits that > > wireless-testing doesn't have yet. > > > > I agree that having to bisect through reverts is not fun, and it takes > > one or two extra iterations. > > Right, which is why I wanted to mention it, will extend the info on > the wiki on the development section once John ACKs/NACKs this.
It should not be necessary to bisect through reverts. I maintain different tags for such purposes. Always use the lastest merge-* tag as the base for bisection. This should be equivalent to whichever -rc release from Linus is the current base for wireless-testing. If you need to go any earlier than that, you should be using linux-2.6. So for example with current tree: git bisect start git bisect bad master-2009-08-19 git bisect good merge-2009-08-14 This should include all of the current wireless patches in wireless-testing but not in the base linux-2.6 kernel. I haven't tracked-down this thread in the archives...am I addressing the issue correctly? Hth! John -- John W. Linville Someday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel