Ray Lee wrote: > On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: >> Why would you care about the merge and not about the individual patches? >> Note that these quilt merges don't have conflicts. > > Because sometimes merges are non-trivial. If you roll that merge > conflict resolution back into the original patch, then the patch is > now different. And in all these rebasings, who's to say there won't be > a typo that accidentally changes the original patch that has had more > testing? We'er all human, y'know? You only focus only on the merges, but I focus on all the other changes too. The reason I maintain patches in quilt is that it's quite easy to fix them up. Besides as a subsystem maintainer the actual conflict points are very rare because normally people don't change drivers/acpi without going through me. >>> It's the difference between having tested patches and an untested >>> merge, or untested new patches >> The patches are as tested individually as they were before. I don't see >> how you can call something that was in linux-next for some time and also >> in my test tree "untested". > > Surely you agree that more testing is better? A rebased patch has had > less testing than the original patch, by definition. What I don't agree on is that a rebased patch had less testing than a patch that got merged by someone else (in this case Linus) into their tree when my tree wasn't at exactly the same point. In both cases it's a merge and yes it is untested initially, but not less so in both of the cases. >>> and an untested merge. >> So when I do a rebase versus Linus doing a merge (end result >> the same code base) how is that more untested? > > If you rebase, you're creating new patches that have less testing than > the originals. You're also tossing away a history of the changesets, > which means that any external testers can no longer point to a > historical potion of a tree and say "I tested that". They can't do that anyways because I maintain my patches in quilt. So there's no canonical such tree. Besides I don't consider it very likely that testers just test my tree (except me myself). Normally testers either test individual patches (e.g. something that is posted as a test patch in bugzilla) or completely merged trees like -mm or linux-next. I am not aware of a significant test population that just pulls ACPI trees only. It really wouldn't make much sense either, testers should really test multiple subsystems in parallel, otherwise testing wouldn't really scale. > Uhm, the history is the whole point of using source control and git. > If all we cared about was the end result and not the history, there'd > be little point to using source management other than to help speed > merging. Sorry, but that's not really how it works. Normally the rule is (and Linus used to encourage that) is that when something hits his tree it shouldn't have the complete development history. Because normally for non trivial changes you would end up with sequences like initial change fix some problems fix more problems found during testing make it compile in configuration foo fix a typo ... etc. [just take a look at some of the version numbers in larger patch series. Often they easily hit double digits. Or sometimes the fix-fix-fix-fix-foo patches in -mm. Of course Andrew tends to clean that up before more] Needless to say such a conglomeration is not bisectable. If your bisect ends in the middle it might not compile or crash in trivial ways etc. Or as a maintainer submitter sends patch version A Then someone finds a problem. Review finds problems. Submitter sends patch version A v2 repeat a few times Or again if you asked to keep the whole history the final merge would have merge A revert A merge Av2 revert Av2 merge Av3 revert Av3 ... Now in a ideal world the person doing the change would get everything right the first time, but we're not living in a ideal world. But when something goes into the Linus tree it just supposed to be a single patch that does this change cleanly without all these additional development steps. Anyways I'm dropping out of this discussion now because I think I made all my points already multiples times. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
