* linux-next: manual merge of acpi tree
@ 2008-06-13 4:53 Stephen Rothwell
2008-06-13 5:09 ` Len Brown
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2008-06-13 4:53 UTC (permalink / raw)
To: Len Brown; +Cc: linux-next, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
Hi Len, Rafael,
Today's linux-next merge of the acpi tree got a context conflict in
drivers/acpi/sleep/main.c between commit
d8f3de0d2412bb91639cfefc5b3c79dbf3812212 ("Suspend-related patches for
2.6.27") from the pci tree and a couple of commits that are duplicate in
the pci and acpi trees ("ACPI PM: acpi_pm_device_sleep_state() cleanup"
and "ACPI PM: Remove obsolete Toshiba workaround").
I used the version from the pci tree.
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: linux-next: manual merge of acpi tree 2008-06-13 4:53 linux-next: manual merge of acpi tree Stephen Rothwell @ 2008-06-13 5:09 ` Len Brown 2008-06-13 6:02 ` Stephen Rothwell 0 siblings, 1 reply; 7+ messages in thread From: Len Brown @ 2008-06-13 5:09 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, Rafael J. Wysocki, Jesse Barnes On Fri, 13 Jun 2008, Stephen Rothwell wrote: > Hi Len, Rafael, > > Today's linux-next merge of the acpi tree got a context conflict in > drivers/acpi/sleep/main.c between commit > d8f3de0d2412bb91639cfefc5b3c79dbf3812212 ("Suspend-related patches for > 2.6.27") from the pci tree and a couple of commits that are duplicate in > the pci and acpi trees ("ACPI PM: acpi_pm_device_sleep_state() cleanup" > and "ACPI PM: Remove obsolete Toshiba workaround"). > > I used the version from the pci tree. > What do you use to merge? Jesse pulled my suspend branch, so you should get the exact same commit id's for 3 patches in both his tree and mine. -Len ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: linux-next: manual merge of acpi tree 2008-06-13 5:09 ` Len Brown @ 2008-06-13 6:02 ` Stephen Rothwell 2008-06-13 8:45 ` Rafael J. Wysocki 0 siblings, 1 reply; 7+ messages in thread From: Stephen Rothwell @ 2008-06-13 6:02 UTC (permalink / raw) To: Len Brown; +Cc: linux-next, Rafael J. Wysocki, Jesse Barnes [-- Attachment #1: Type: text/plain, Size: 1539 bytes --] Hi Len, On Fri, 13 Jun 2008 01:09:31 -0400 (EDT) Len Brown <lenb@kernel•org> wrote: > > On Fri, 13 Jun 2008, Stephen Rothwell wrote: > > > Today's linux-next merge of the acpi tree got a context conflict in > > drivers/acpi/sleep/main.c between commit > > d8f3de0d2412bb91639cfefc5b3c79dbf3812212 ("Suspend-related patches for > > 2.6.27") from the pci tree and a couple of commits that are duplicate in > > the pci and acpi trees ("ACPI PM: acpi_pm_device_sleep_state() cleanup" > > and "ACPI PM: Remove obsolete Toshiba workaround"). > > What do you use to merge? git, gitk and vi (and my eyes :-)) > Jesse pulled my suspend branch, so you should get the exact same commit > id's for 3 patches in both his tree and mine. they are not the same commits: "ACPI PM: acpi_pm_device_sleep_state() cleanup" 06166780eb53685e72b589814d535d1f9948e761 in the pci tree 0cc5ddb904162f611568d4db66ccd8af61dffc16 int the acpi tree "ACPI PM: Remove obsolete Toshiba workaround" 0e6859d49ff194e01afc229c996e3aefca1a0539 in the pci tree f7259bd5d588d59816e1f4d5d4f3da9382916dac in the acpi tree In the acpi tree (I pull the test branch into linux-next) the former has a different parent to the one on the pci tree since Jesse pulled your "suspend" branch into his pci tree. So the git merge sees them as overlapping changes to the same file (as well as the other commit above) and generates a conflict. -- Cheers, Stephen Rothwell sfr@canb•auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: linux-next: manual merge of acpi tree 2008-06-13 6:02 ` Stephen Rothwell @ 2008-06-13 8:45 ` Rafael J. Wysocki 2008-06-13 15:49 ` linux-next: managing a web of git trees Jesse Barnes 0 siblings, 1 reply; 7+ messages in thread From: Rafael J. Wysocki @ 2008-06-13 8:45 UTC (permalink / raw) To: Stephen Rothwell; +Cc: Len Brown, linux-next, Jesse Barnes On Friday, 13 of June 2008, Stephen Rothwell wrote: > Hi Len, > > On Fri, 13 Jun 2008 01:09:31 -0400 (EDT) Len Brown <lenb@kernel•org> wrote: > > > > On Fri, 13 Jun 2008, Stephen Rothwell wrote: > > > > > Today's linux-next merge of the acpi tree got a context conflict in > > > drivers/acpi/sleep/main.c between commit > > > d8f3de0d2412bb91639cfefc5b3c79dbf3812212 ("Suspend-related patches for > > > 2.6.27") from the pci tree and a couple of commits that are duplicate in > > > the pci and acpi trees ("ACPI PM: acpi_pm_device_sleep_state() cleanup" > > > and "ACPI PM: Remove obsolete Toshiba workaround"). > > > > What do you use to merge? > > git, gitk and vi (and my eyes :-)) > > > Jesse pulled my suspend branch, so you should get the exact same commit > > id's for 3 patches in both his tree and mine. > > they are not the same commits: > "ACPI PM: acpi_pm_device_sleep_state() cleanup" > 06166780eb53685e72b589814d535d1f9948e761 in the pci tree > 0cc5ddb904162f611568d4db66ccd8af61dffc16 int the acpi tree > "ACPI PM: Remove obsolete Toshiba workaround" > 0e6859d49ff194e01afc229c996e3aefca1a0539 in the pci tree > f7259bd5d588d59816e1f4d5d4f3da9382916dac in the acpi tree > > In the acpi tree (I pull the test branch into linux-next) the former has > a different parent to the one on the pci tree since Jesse pulled your > "suspend" branch into his pci tree. > > So the git merge sees them as overlapping changes to the same file (as > well as the other commit above) and generates a conflict. Well, the commits will always be different, because they depend on the previous commits and those are different in both trees. The files they modify, however, should be exactly the same finally. I don't know how to handle that cleanly. :-( Thanks, Rafael ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: linux-next: managing a web of git trees 2008-06-13 8:45 ` Rafael J. Wysocki @ 2008-06-13 15:49 ` Jesse Barnes 2008-06-13 16:01 ` Linus Torvalds 0 siblings, 1 reply; 7+ messages in thread From: Jesse Barnes @ 2008-06-13 15:49 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Stephen Rothwell, Len Brown, linux-next, Linus Torvalds On Friday, June 13, 2008 1:45 am Rafael J. Wysocki wrote: > > they are not the same commits: > > "ACPI PM: acpi_pm_device_sleep_state() cleanup" > > 06166780eb53685e72b589814d535d1f9948e761 in the pci tree > > 0cc5ddb904162f611568d4db66ccd8af61dffc16 int the acpi tree > > "ACPI PM: Remove obsolete Toshiba workaround" > > 0e6859d49ff194e01afc229c996e3aefca1a0539 in the pci tree > > f7259bd5d588d59816e1f4d5d4f3da9382916dac in the acpi tree > > > > In the acpi tree (I pull the test branch into linux-next) the former has > > a different parent to the one on the pci tree since Jesse pulled your > > "suspend" branch into his pci tree. > > > > So the git merge sees them as overlapping changes to the same file (as > > well as the other commit above) and generates a conflict. > > Well, the commits will always be different, because they depend on the > previous commits and those are different in both trees. The files they > modify, however, should be exactly the same finally. > > I don't know how to handle that cleanly. :-( Yuck, I thought they'd retain the same commit ids for some reason. OTOH if the content is the same, resolving the conflicts should be trivial (git might even do it automatically at merge time if it's identical?). Linus, do you have any suggestions for this case? We've been trying to pull different trees together to make merging & management easier, but it's not working as smoothly as we'd like. My pull of Ingo's PCI changes worked pretty well (after merging his branch all the identical commits ended up the same), but my pull of Len's suspend branch didn't work that way... Thanks, Jesse ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: linux-next: managing a web of git trees 2008-06-13 15:49 ` linux-next: managing a web of git trees Jesse Barnes @ 2008-06-13 16:01 ` Linus Torvalds 2008-06-13 16:28 ` Jesse Barnes 0 siblings, 1 reply; 7+ messages in thread From: Linus Torvalds @ 2008-06-13 16:01 UTC (permalink / raw) To: Jesse Barnes; +Cc: Rafael J. Wysocki, Stephen Rothwell, Len Brown, linux-next On Fri, 13 Jun 2008, Jesse Barnes wrote: > On Friday, June 13, 2008 1:45 am Rafael J. Wysocki wrote: > > > they are not the same commits: > > > "ACPI PM: acpi_pm_device_sleep_state() cleanup" > > > 06166780eb53685e72b589814d535d1f9948e761 in the pci tree > > > 0cc5ddb904162f611568d4db66ccd8af61dffc16 int the acpi tree > > > "ACPI PM: Remove obsolete Toshiba workaround" > > > 0e6859d49ff194e01afc229c996e3aefca1a0539 in the pci tree > > > f7259bd5d588d59816e1f4d5d4f3da9382916dac in the acpi tree > > > > > > In the acpi tree (I pull the test branch into linux-next) the former has > > > a different parent to the one on the pci tree since Jesse pulled your > > > "suspend" branch into his pci tree. > > > > > > So the git merge sees them as overlapping changes to the same file (as > > > well as the other commit above) and generates a conflict. > > > > Well, the commits will always be different, because they depend on the > > previous commits and those are different in both trees. The files they > > modify, however, should be exactly the same finally. > > > > I don't know how to handle that cleanly. :-( > > Yuck, I thought they'd retain the same commit ids for some reason. OTOH if > the content is the same, resolving the conflicts should be trivial (git might > even do it automatically at merge time if it's identical?). > > Linus, do you have any suggestions for this case? We've been trying to pull > different trees together to make merging & management easier, but it's not > working as smoothly as we'd like. My pull of Ingo's PCI changes worked > pretty well (after merging his branch all the identical commits ended up the > same), but my pull of Len's suspend branch didn't work that way... The fact that they are different commits matters not at all to the git merge strategy. The git merge strategy is in fact expressly designed to not care about how some state came to be, it only cares about - what was the last _common_ state (and if there are multiple such points, it does the merge recursively for those multiple common states) - what were the end results. So the fact that "the commits will always be different" is irrelevant. Yes, the commits will be different because they have different history, but it has no relevance for the merge strategy. It will not cause conflicts just because two different commits touch the same area. The only thing the merge strategy cares about is the actual *state* of the files. However, since conflicts clearly happen, let's look at what *does* cause conflicts. It's not the existence of the same patch to the same area in a file. It's about *different* patches to the same area in a file. If you have two development trees that have the exact same changes to some area in a file, then the merge algorithm with be very happy, and just merge those changes. It's the standard three-way merge. HOWEVER! If there are _other_ changes that overlap (and aren't identical), then *that* is when conflicts happen. And that is true regardless of whether the history also contains some identical changes. IOW, if you have - patch A (in _both_ histories) - patch B (in just _one_ of the histories) and they overlap, then that will be a conflict. And now, since the original file will have *neither* A nor B, the conflict will basically be the union of A and B - the three-way merge does not care at all about the fact hat A existed twice, because qutie frankly, maybe B was a _fix_ to A, and even though A exists in both branches, it may well be that A on it's own is pure and utter sh*t and shoult not be merged. See? So identical patches (with different commits) in two trees is not what causes problems. It's the *non-identical* ones that cause problms. And if they overlap with the identical ones, even partially, then yes, you'll have to resolve not just the non-identical ones, but the identical ones too. Linus ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: linux-next: managing a web of git trees 2008-06-13 16:01 ` Linus Torvalds @ 2008-06-13 16:28 ` Jesse Barnes 0 siblings, 0 replies; 7+ messages in thread From: Jesse Barnes @ 2008-06-13 16:28 UTC (permalink / raw) To: Linus Torvalds; +Cc: Rafael J. Wysocki, Stephen Rothwell, Len Brown, linux-next On Friday, June 13, 2008 9:01 am Linus Torvalds wrote: > On Fri, 13 Jun 2008, Jesse Barnes wrote: > > On Friday, June 13, 2008 1:45 am Rafael J. Wysocki wrote: > > > > they are not the same commits: > > > > "ACPI PM: acpi_pm_device_sleep_state() cleanup" > > > > 06166780eb53685e72b589814d535d1f9948e761 in the pci tree > > > > 0cc5ddb904162f611568d4db66ccd8af61dffc16 int the acpi tree > > > > "ACPI PM: Remove obsolete Toshiba workaround" > > > > 0e6859d49ff194e01afc229c996e3aefca1a0539 in the pci tree > > > > f7259bd5d588d59816e1f4d5d4f3da9382916dac in the acpi tree > > > > > > > > In the acpi tree (I pull the test branch into linux-next) the former > > > > has a different parent to the one on the pci tree since Jesse pulled > > > > your "suspend" branch into his pci tree. > > > > > > > > So the git merge sees them as overlapping changes to the same file > > > > (as well as the other commit above) and generates a conflict. > > > > > > Well, the commits will always be different, because they depend on the > > > previous commits and those are different in both trees. The files they > > > modify, however, should be exactly the same finally. > > > > > > I don't know how to handle that cleanly. :-( > > > > Yuck, I thought they'd retain the same commit ids for some reason. OTOH > > if the content is the same, resolving the conflicts should be trivial > > (git might even do it automatically at merge time if it's identical?). > > > > Linus, do you have any suggestions for this case? We've been trying to > > pull different trees together to make merging & management easier, but > > it's not working as smoothly as we'd like. My pull of Ingo's PCI changes > > worked pretty well (after merging his branch all the identical commits > > ended up the same), but my pull of Len's suspend branch didn't work that > > way... > > The fact that they are different commits matters not at all to the git > merge strategy. The git merge strategy is in fact expressly designed to > not care about how some state came to be, it only cares about > > - what was the last _common_ state (and if there are multiple such > points, it does the merge recursively for those multiple common states) > > - what were the end results. > > So the fact that "the commits will always be different" is irrelevant. > Yes, the commits will be different because they have different history, > but it has no relevance for the merge strategy. It will not cause > conflicts just because two different commits touch the same area. The only > thing the merge strategy cares about is the actual *state* of the files. > > However, since conflicts clearly happen, let's look at what *does* cause > conflicts. It's not the existence of the same patch to the same area in a > file. It's about *different* patches to the same area in a file. > > If you have two development trees that have the exact same changes to some > area in a file, then the merge algorithm with be very happy, and just > merge those changes. It's the standard three-way merge. > > HOWEVER! If there are _other_ changes that overlap (and aren't identical), > then *that* is when conflicts happen. And that is true regardless of > whether the history also contains some identical changes. IOW, if you have > > - patch A (in _both_ histories) > - patch B (in just _one_ of the histories) > > and they overlap, then that will be a conflict. And now, since the > original file will have *neither* A nor B, the conflict will basically be > the union of A and B - the three-way merge does not care at all about the > fact hat A existed twice, because qutie frankly, maybe B was a _fix_ to A, > and even though A exists in both branches, it may well be that A on it's > own is pure and utter sh*t and shoult not be merged. > > See? Right, that's what I would expect; and I was pretty sure that there wouldn't be problems for different commits with identical content, but I wanted to be sure. > So identical patches (with different commits) in two trees is not what > causes problems. It's the *non-identical* ones that cause problms. And if > they overlap with the identical ones, even partially, then yes, you'll > have to resolve not just the non-identical ones, but the identical ones > too. I guess I should be glad we don't have more real conflicts in this case. I suppose I could also pull whatever dependent fixes were required into my tree (or Len could pull from mine into his) to make Stephen's life easier... Thanks, Jesse ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-06-13 16:28 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-06-13 4:53 linux-next: manual merge of acpi tree Stephen Rothwell 2008-06-13 5:09 ` Len Brown 2008-06-13 6:02 ` Stephen Rothwell 2008-06-13 8:45 ` Rafael J. Wysocki 2008-06-13 15:49 ` linux-next: managing a web of git trees Jesse Barnes 2008-06-13 16:01 ` Linus Torvalds 2008-06-13 16:28 ` Jesse Barnes
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox