Re: [GIT PATCH] thinkpad-acpi queue for the 2.6.26 merge window

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Thu, 10 Apr 2008, Richard Purdie wrote:
> On Thu, 2008-04-10 at 13:23 -0400, Len Brown wrote:
> > If the patches that Henrique depends on are unlikely to change,
> > then I'll be happy to put them on a branch in my tree and put
> > henrique's driver on top of them.  If they go upstream via your
> > tree and/or mine and are identical, then that works fine.
> > 
> > However, if i check them into my tree and then you push a
> > different version upstream, then we'd have a merge conflict.
> > 
> > Please let me know what you suggest.
> 
> Those patches are queued and I have no plans to change them before
> submitting to Linus. 
> 
> When you say identical, do you mean the patches themselves or also the
> commit and object IDs? 

The object IDs can't be the same, unless Len base his acpi-tree on
yours, or you base your tree on his, AFAIK.  Since both you AND Len
usually rebase to latest linus before sending a pull request (which is
nicer to people doing bissections and far less patch-mismerge-prone),
this will be unoptimal to both of you.

So, suppose then that the object IDs are different (i.e. Len merged your
tree into acpi-test, and Linus merged it in mainline), BUT that the
resulting blobs are the same for the files that are affected by BOTH
trees being merged at the same time:

Git simply does the right thing, notices the file are the same, doesn't
complain, and if you look at the history, your patches will be in the
history twice: once in Len's branch that was merged, and once in
mainline where Linus merged it.  Which is exactly what happened anyway,
and thus, correct.   It will also do the right thing on bissects, etc.

However, if at the point Len's tree is merged in mainline, anything else
already touched the files and changed them beyond what your tree (as
merged by Len) had... conflicts might arrise.

IMHO, the easiest solution here is for Len to hold my thinkpad-acpi
patches a small bit, and land them in acpi-test only after Richard's are
upstream.  This means the thinkpad-acpi patches get less testing in
acpi-test before they land in mainline either in late rc1 or before
rc2...  but these patches are already being tested outside of acpi-test
anyway, and they can't do more than break thinkpad-acpi, which I can
swiftly fix and won't cause trouble anywhere else in the kernel.

So Len, since I did meet the required lead time window for acpi-test
submission :-) and if you don't have anything against a somewhat later
merge of thinkpad-acpi for 2.6.26's merge window or for 2.6.26-rc1, we
could probably just take the easy way, and merge thinkpad-acpi in
acpi-test after Richard's LED tree is in mainline already.

Meanwhile, I will resend the patch series with the typos Randy pointed
out fixed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh