On Thu, 17 Jul 2008, Andi Kleen wrote: > > Hmm, but if you're dependent ACPI needs to go in first anyways, doesn't it? Umm. The particular PART of ACPI you depend on needs to go in first, yes. That's the whole point of topic branches. They allow you to separate out work to different areas, so that people who are interested in (say) the PCI-impacting ones can merge with one part, without having to wait for the other parts to stabilize. > I don't think the ACPI tree is dependent on PCI at least. Or at least I didn't > notice any problems in this area. The PCI tree merged the suspend branch from the ACPI tree. You can see it by lookin gat the PCI merge in gitk: gitk dc7c65db^..dc7c65db and roughly in the middle there you'll find Jesse's commit 53eb2fbe, in which he merges branch 'suspend' from Len's ACPI tree. So Jesse got these three commits: 0e6859d... ACPI PM: Remove obsolete Toshiba workaround 8d2bdf4... PCI ACPI: Drop the second argument of platform_pci_choose_state 0616678... ACPI PM: acpi_pm_device_sleep_state() cleanup from Len's tree. Then look at these three commits that I got when I actually merged from you: 741438b... ACPI PM: Remove obsolete Toshiba workaround a80a6da... PCI ACPI: Drop the second argument of platform_pci_choose_state 2fe2de5... ACPI PM: acpi_pm_device_sleep_state() cleanup Look familiar? It's the same patches - just different commit ID's. You rebased and moved them around, so they're not really the "same" at all, and they don't show the shared history any more, and the fact that they were pulled earlier into the PCI tree (and then into mine). This is what rebasing causes. Linus -- 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
