Linus,

Please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-merge-2.6 release-2.6.27

to get the initial ACPI updates for 2.6.27. We got a few more changes
dependent on yet unpulled trees and some other candidate patches,
but that's the bulk for the changes intended for 2.6.27. Most of that
has been collected by Len Brown before he went on sabbatical. I was
relatively conservative with additional changes so far.

-Andi

Aaron Durbin (1):
      Add the ability to reset the machine using the RESET_REG in ACPI's FADT table.

Adrian Bunk (1):
      eeepc-laptop: static

Alan Cox (1):
      snapshot: Push BKL down into ioctl handlers

Alok N Kataria (1):
      ACPI: fix checkpatch.pl complaints in scan.c

Bjorn Helgaas (29):
      PNP: add detail to debug resource dump
      PNP: remove pnp_resource.index
      PNP: add pnp_resource_type() internal interface
      PNP: add pnp_resource_type_name() helper function
      PNP: make pnp_{port,mem,etc}_start(), et al work for invalid resources
      PNP: replace pnp_resource_table with dynamically allocated resources
      PNPACPI: keep disabled resources when parsing current config
      PNP: remove ratelimit on add resource failures
      PNP: dont sort by type in /sys/.../resources
      PNP: add pnp_possible_config() -- can a device could be configured this way?
      PNP: whitespace/coding style fixes
      PNP: define PNP-specific IORESOURCE_IO_* flags alongside IRQ, DMA, MEM
      PNP: make resource option structures private to PNP subsystem
      PNP: introduce pnp_irq_mask_t typedef
      PNP: increase I/O port & memory option address sizes
      PNP: improve resource assignment debug
      PNP: in debug resource dump, make empty list obvious
      PNP: make resource assignment functions return 0 (success) or -EBUSY (failure)
      PNP: remove redundant pnp_can_configure() check
      PNP: centralize resource option allocations
      PNPACPI: ignore _PRS interrupt numbers larger than ...
[ message continues ]

Well, IMO it would be better to merge PCI first.

Thanks,
Rafael
--

[ message continues ]

Yeah, they're interdependent (I pulled from Len's tree, hopefully Andi 
preserved the changesets).  I had wanted to do a little more testing of what 
I've got, but I haven't heard any huge complaints so far so maybe things are 
ok.  I'll generate a pull request now.

Jesse
--

[ message continues ]

Andi did not. The whole series I pulled was rebased today at 2PM.

I was going to complain about it, because Len's trees were always a 
pleasure to pull with clearly delineated topic branches etc, and pulling 
from Andi was such a let-down in comparison.

But I decided to let it slide, because quite frankly, Len had done better 
than the average bear, and I didn't realize that the commits Andi had 
rebased had actually been in Len's tree in the _good_ format.

It seems I was wrong - I should _not_ have let it slide, and it appears 
that Andi had actually destroyed Len's pretty tree.

Andi. This can _not_ continue. You need to learn how to use topic 
branches, and how to not screw up other peoples trees. Otherwise I'll just 
have to stop pulling from you. AGAIN.

			Linus
--

[ message continues ]

Ugg, when Andi took over we talked about it; I thought we had agreed that he 

Is a topic branch flow like what Len uses documented somewhere that you know 
of?  I know my process could use some improvement; I'd rather not have to 
wait for Len to come back to ask him. :)

Thanks,
Jesse
--

[ message continues ]

Well, I haven't actually seen Len's original tree, so maybe the stuff Andi 
pushed was just the stuff he had queued up independently. I guess I 

Len wrote it up at one point, but I can't for the life of me remember 
where. 

He's not the onyl one to ask, though - Ingo and Thomas seem to have picked 
up topic branches pretty well (I had some issues with a couple of the 
topics, but they weren't fundamental and the major one was probably 
because Ingo tried a bit too hard to make sure that I never saw any 
conflicts at all).

Other topic branch users include Jeff Garzik and rmk. There's definitely 
people around who should be able to talk about what they are doing.

		Linus
--

[ message continues ]

No, he rebased it - the three commits you shared are now separate ones. 

Most of the conflicts seem to have been due tot he x86 tree changes 
though. But it seems I didn't mess up too much: at least the result booted 
for me without complaints. So I pushed out my resolution.

Jesse, can you please double-check it?

			Linus
--

[ message continues ]

Well, I could have misunderstood what we talked about; I guess I just assumed 
Andi & I would chat before sending out our pull requests.  I'll be sure to 

Just looked, seems fine.  I'd pat you on the head to reassure you about it, 
but my arms aren't quite long enough...

I'll dig around some more for git best practices too.  Based on what I've seen 
of the x86 tree I don't have nearly enough branches (though on the plus side, 
I almost never rebase since I don't want to hose any downstream users, and I 
don't merge from your tree until after you've pulled to avoid cluttering up 
the log).

Thanks,
Jesse
--

[ message continues ]

Don't worry about it. Start small. I think the x86 tree took up some 
pretty extreme limits, as can be seen by their 29-way merge or whatever it 
was. They also obviously have a lot more stuff going on than the PCI tree 
would be expected to have.

For most people, I'd expect that a small handful of branches is good. It 
might be just one, but it might be a couple of independent issues.

The point where a topic branch is _really_ useful is when you ask yourself 
whether that particular change is something that you (or somebody else!) 
might want to delay or test separately from some other change - that's 
when "oh, let's just use a separate branch for it" is really appropriate.

Len, for example, often did topic branches for individual bugzilla 
entries, and obviously for big conceptually separate things like ACPICA, 
which really _is_ a totally disjoint development track.

Other people, like rmk, use topic branches for particular hardware 
platforms.

On the other hand, if it's a trivial and obvious thing, there's no point 
in putting it into a separate branch. A number people who keep topic 
branches for all their major development then end up having a "misc" 
branch for just random things.

And remember: in git, topic branches are temporary things. You can rename 
them, you can delete them, you can ignore them. And before you've pushed 
things out, you can even decide to create a topic branch of a set of 
commits _after_ the fact. So you can commit _first_, and then decide that 
that commit was probably best to keep separate, so you create a topic 
branch with that commit on it, an go back to the pre-commit state on your 
regular branch.

BUT!

 - Not everybody _has_ to use topic branches. If you are maintaining 
   something that is very specific to begin with, _all_ your maintenance 
   is basically one topic to start with, so you'd never have separate 
   topic branches.

   The filesystem people, for example, do not tend to use topic branches 
   for this ...
[ message continues ]

I originally started with topic branches and imported a few patches
this way, but then eventually realized they don't really match my
working style. In particular I tend to edit and sometimes
delete old patches and that seems to be quite painful with
the topic branch setup (or perhaps I just haven't figured out
how to do it nicely). Also tried it with guilt, but that
also ran into some issues (in particular after merges one
cannot manage the patches as a guilt stack anymore)

What I did then was to export Len's tree to quilt, do all the touchups
etc, merged some more patches and then regenerated a quilt tree for
the merge request. That is how the old x86-64 tree used to work.

-Andi
--

[ message continues ]

Right. 

And Andi, remember the problems with that one? Remember how I ended up 
refusing to 'git pull' from you? (Also look at how it failed to work well 
for Ingo and Thomas as well, and how people complained about that? It's 
not just you.)

In other words, "That is how the old x86-64 tree used to NOT work".

			Linus
--

[ message continues ]

I went back to quilt because the topic branches didn't really

My plan was to keep everything in quilt and just regenerate for the pull.
Please let me know if it's now not allowed anymore to use quilt.

-Andi
--

[ message continues ]

End-point developers can use quilt all thei like.

But people cannot and *MUST NOT* destroy other peoples work with quilt, 
nor make it harder for people to share commits.

Len had apparently left a nice topic tree for you. You took that work, and 
then destroyed it. And yes, it is noticeable: Jesse had shared some of the 
work from Len by pulling one of the branches (the 'suspend' branch), and 
then you literally re-wrote _public_ history, so now tohose patches are 
duplicated.

Now, duplicate patches happen, and that's not a huge technical issue (most 
of the time it all merges cleanly, and it was just three patches this 
time), but if you're going to rebase stuff, you're basically making it 
impossible for people to share work with you. They can never rely on your 
git trees, because your git threes are all throw-away.

Btw, being throw-away also means that they get essentially no testing. 
They get rewritten each time, so even if you expose them to something like 
linux-next and they get testing there, when you rebase them, the end 
result is something *different*, and a lot of the test coverage goes away.

See the discussion from May about the x86 tree. I don't have it online in 
my archives any more, but google finds

	http://kerneltrap.org/Linux/Git_Management

which has at least a big part of the discussion in one readable page.

So no, there's nothing wrong with a quilt interface. But there _is_ 
something wrong with a maintainer that makes it harder for other people 
(in this case Jesse) to work with him, because he destroys history.

		Linus
--

[ message continues ]

Andi, Jesse, Linus,

Thanks for working through this while I'm away.

Patches with cross-tree dependencies happen,
and they continue to be a challenge to our process.
We don't really have an organized way to handle them.
It seems that every time they are a communication challenge
and I'm sorry I wasn't there to hold up my
end of the communication on this merge.

Jesse,

I use Tony Luck's topic-branch scheme, now part of the git manual:

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#maintaining-topic-bra...

Re: updating history in git
yes, this is an sort of an oxymoron, but it is necessary
for a "middle-man" maintainer.
On one hand, we need to test exactly what is checked in,
and on the other hand, not every test passes...
So we need to revise what we checked in before it goes upstream
and becomes permanent history.

The alternative would be to check in a lot of reverts
and incremental patches that make the final history
sent to linus really confusing.

I find that the topic branches help a lot with this.
My "test" branch is the merge of a bunch of topic branches.
If a topic branch turns out to be bad, I can re-merge my test
branch from those topics, excluding the bad one.
(or including a revised replacement).

All the branches besides the revised one maintain
their place in history.  So if they used to work,
they shoulds still work.  Of course the merge itself
can go bad...  But my topic branches are as independent
as possible, so this is rare.

Customers of my test branch know that it can be re-based.
mm and linux-next are the main customers, and since
they re-merge from scratch each time, they're immune.
Individual developers simply deal with it as a diff,
say by using the plain-patch I export, or I do something special for them.

Sometimes I re-base topic branches to make
creating a diff of them versus a well known snapshot
(eg an -rc) easy.  This is particularly useful for
topic branches that take a long time to go upstream
b/c ...
[ message continues ]

git rebase --interactive

sounds like exactly what you are asking for.

Harvey

--

[ message continues ]

Sounds like a nice feature. Thanks for the pointer.

-Andi
--

[ message continues ]

Actually, it _is_ easier, although apparently the thing that made it 
easier isn't necessarily widely known or documented.

I'm going to quote your whole sequence, because it's not a really odd 
thing do want to do, and quoting how you do it now also makes the "proper 

No, what others do (if they know the tricks) is to say something like:

	git rebase -i <starting-point>

("-i" is short for "--interactive") where the starting point is just where 
you want to start your work. It might be "origin", or it might be 
"HEAD~30" to say "30 commits ago" or whatever. Anyway, it's basically the 
stable point before the place you want to fix up.

That thing will literally show you the list of commits in an editor, and 
then you can re-order them or mark them for special actions.

The normal action is to "pick" the commit (ie you just cherry-pick it). 
But rather than just picking a commit (remember - you can change the order 
by just editing the list), you can also do

 - "edit": this just basically pauses the rebase after committing the 
    cherry-pick, so that you can then edit things and fix them with "git 
    commit --amend", and when you're happy, you do "git rebase --continue"
    to continue your series.

 - "squash": this squashes the commit in togethr with the previous one, 
   and is very useful together with moving commits around. IOW, maybe you 
   committed a fix to a previous commit, and want to integrate the fix 
   into the original commit - in that case you'd move the commit in the 
   list up to just after the commit you want to fix, and change the "pick" 
   into a "squash"

so it actually makes doing what you do above by hand much easier.

[ Honesty in advertising: I actually don't use this at all. I've tested 
  it, and I think it's very useful, but I have so far mostly ended up 
  doing this by hand in the very few cases I do it at all. Part of the 
  reason is that "git rebase -i" is fairly recent, so it's not part of my 
  normal tool set.

  But ...
[ message continues ]

Oh, and before anybody goes any further with this: it's a very convenient 
feature, but it _is_ still technically nothing but a very nice interface 
to cherry-picking and rebasing history. 

So all the caveats about _not_ doing this with public history that others 
have already seen and possibly merged are still in place. That part 
doesn't change at all.

So it's great to do with private changes to clean them up before 
publicizing them, or possibly with branches that you have explicitly told 
people are _not_ stable, but it is still very much about creating a 
totally new history.

			Linus
--

[ message continues ]

Linus's answer (with rebase -i) is probably better, but my habit is to

Instead of the above three steps, you can do just:

  $ edit

At this point I do

	git rebase --onto HEAD old-sha1 name-of-branch-to-rebase

(where old-sha1 is the name of the commit we just replaced, which I
usually cut-n-paste out of gitk).  That rebases the commits in the range
old-sha1...name-of-branch-to-rebase onto the new HEAD commit that you

That works too.

--b.
--

[ message continues ]

It's not only about destroying work and history, it can be worse than that.

For example look at commits:

816c2eda3ce8fa7eb62f22e01e2ec7a3f7d677c0 (merged between 2.6.26-rc8 and -rc9)
and
cc7e51666d82aedfd6b9a033ca1a10d71c21f1ca (merged now)

The export to quilt and the lazy default fuzz setting of quilt added
aside of Andi's Signed-off-by the following gem:

commit cc7e51666d82aedfd6b9a033ca1a10d71c21f1ca
Author: Len Brown <len.brown@intel.com>
Date:   Tue Jun 24 22:57:12 2008 -0400

    dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled.
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>

diff --git a/drivers/acpi/bay.c b/drivers/acpi/bay.c
index 61b6c5b..e6caf5d 100644
--- a/drivers/acpi/bay.c
+++ b/drivers/acpi/bay.c
@@ -380,6 +380,9 @@ static int __init bay_init(void)
 	if (acpi_disabled)
 		return -ENODEV;
 
+	if (acpi_disabled)
+		return -ENODEV;
+
 	/* look for dockable drive bays */
 	acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
 		ACPI_UINT32_MAX, find_bay, &bays, NULL);
diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
index bb7c51f..1e872e7 100644
--- a/drivers/acpi/dock.c
+++ b/drivers/acpi/dock.c
@@ -920,6 +920,9 @@ static int __init dock_init(void)
 	if (acpi_disabled)
 		return 0;
 
+	if (acpi_disabled)
+		return 0;
+
 	/* look for a dock station */
 	acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
 			    ACPI_UINT32_MAX, find_dock, &num, NULL);

[ Note the code duplication in both files ]

I stumbled accross this incidentally while looking at the recent merge
commits.

While this one looks odd but harmless, probably a full audit of all
the affected commits should be done.

Please revert the one I happened to notice. Patch below.

Thanks,

	tglx

----------->
Subject: APCI: revert duplicated patch
From: Thomas Gleixner <tglx@linutronix.de>

commit 816c2eda3ce8fa7eb62f22e01e2ec7a3f7d677c0
    dock: bay: Don't call ...
[ message continues ]

Good catch. Thanks. I'll queue a revert.

-Andi
--

[ message continues ]

Another one.

Thanks,
 
 	tglx
 
----------->
Subject: APCI: revert another duplicated patch
From: Thomas Gleixner <tglx@linutronix.de>

commit d1857056904d5f313f11184fcfa624652ff9620a

is another superfluous duplicate commit caused by
git -> quilt -> git conversion.

Revert it.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 

---
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 6d18ca3..9b227d4 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -336,9 +336,6 @@ static int __init acpi_rtc_init(void)
 	if (acpi_disabled)
 		return 0;
 
-	if (acpi_disabled)
-		return 0;
-
 	if (dev) {
 		rtc_wake_setup();
 		rtc_info.wake_on = rtc_wake_on;
--

[ message continues ]

Hmm, but if you're dependent ACPI needs to go in first anyways, doesn't it?

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.

-Andi

--

[ message continues ]

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 

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
--

[ message continues ]

Btw, you don't really have to have a lot of them.

When it comes to ACPI in particular, I would really prefer to see at least 
the ACPICA stuff in a separate topic branch. It comes in from a different 
source, it's maintained separately, and when it causes problems(*) it ends 
up usually being handled differently too.

Len additionally split things like bugzilla entries up into individual 
topics, and that was really nice to see when merging, but I have to say 
that it was also "above and beyond" what I've ever expected of any 
maintainer. That said, I think ACPI has been rather bugzilla-driven (many 
other areas are feature-driven), and I do think it makes tons of sense to 
put fixes in different branches, and then you can merge them when you 
actualyl close the bug when the fix has been verified.

So one reason I reacted strongly to the ACPI change was definitely just 
that ACPI used to be one of the really nicely done subsystems (not just 
from a git standpoint, but the whole git flow was part of it). There were 
some issues very early on in git usage, but I gave a shout-out to Len at 
the last kernel summit for a reason.

And in that sense it's definitely unfair to require quite _that_ level of 
separation. I'm really not expecting it. 

But I *really* hate pulling from somebody, and seeing commit dates that 
are from five minutes ago, and based on something that I had just pushed 
out (which was essentially the case for this round of ACPI changes).

That literally shows that the code was hardly tested _at_all_ in that 
exact configuration. It may have gotten testing based on some earlier 
kernel version, but then it very clearly got rebased (or just quilt 
imported) on top of a totally new kernel base, and was not tested in that 
version very much if at all.

So even if you end up using quilt, I'd suggest you do so on a specific 
base, rather than on some random "kernel-of-the-moment-in-the-middle- 
of-the-merge-window". Because then at least I feel like the ...
[ message continues ]

And Andi, before this goes any further, I'd like to say that (a) no, I 
don't hate you and (b) sorry in advance and in retrospect for my obviously 
abrasive personality and just being harsh.

In particular, this is something that I have gone through with a _lot_ of 
maintainers. So you don't need to feel bad about it. Ingo and Thomas 
obviously did the very same thing not that long ago.

And Davem had the same issue in the networking tree - most of the times 
when I pulled, I could tell that he had _just_ rebased the whole series, 
and I just knew that it had gotten effectively zero testing in that 
particular configuration.

For other trees it's still ongoing: you can generally trivially tell by 
looking at the merges and the dates of the commits relative to them and 
'base' they are done on top of. 

So you're definitely not alone. There are people who have done the same 
thing, and in many cases they did it for months. I'll happily try to help 
you with any git issues, and we can even change git itself to help with 
some things (historically we certainly have - I certainly hope that the 
need for it is going away, though). 

And I can also report that the people who then re-learnt their workflow 
and got used to maintaining several queues and not always working at the 
top of the tree and rebasing on top of whatever "random Linus kernel of 
the moment" (in order to actually work with and test what they eventually 
ask me to pull!) have so far been pretty enthusiastic about the workflow 
they learn once they pick it up.

And to give them credit for being smarter them me, others (like Jeff) 
started doing the whole "many different branches" thing long before I 
personally even realized how helpful it is.

And as mentioned, some still use the "queue on top of the most recent 
version" model, and when it's something fairly far away in the periphery 
and doesn't impact others, I don't really care. If it hadn't been for the 
PCI merge bringing up the issue, I'd have ...
[ message continues ]

Ok I can do that one separately.

I think my main problem was that it seemed so painful to change old
commits and I ended up accumulating ugly reverts and incremental changes,
but perhaps I just need to do better frontend scripts to make


Hmm, perhaps I'm thick, but for me the only difference seems to be
that the submitter does the merge that you would do (and safes
himself a yelling at if it doesn't build or crashes at boot or similar...).

In both  cases there's a "untested in that configuration" end configuration
in the end, but there's nothing much that can be done against it,

That is what I usually do. I use the last -git* snapshot. I just updated
the git tree shortly before I generate the merge tree just to make
sure it still builds in your current tree.

Given it won't be tested much in that newer configuration then (I actually
test booted it on a few systems at least[1]), but that would be the same on your
side, wouldn't it?

-Andi

[1] which was quite painful this time because I ran into several problems
outside ACPI. e.g. DMAR oopsed and the x86 defconfigs were totally broken
and some other issues.
--

[ message continues ]

It matters to us end-testers when we do a git bisect. If you leave the
history intact and let the merging happen at Linus' end (or, at least
at merge time), then there is a point in history of your tree that
someone (or git bisect) can check out and try, validating the patch,
and therefore fingering a failed merge.

It's the difference between having tested patches and an untested
merge, or untested new patches and an untested merge. Your point is
the end result is untested either way. The other way to look at it is
*how much* untested history ends up in the tree. In Linus' version,
just the point from the merge onward is untested. In your version,
everything is new.
--

[ message continues ]

The whole point of the exercise of cleaning up/rewriting the history is to make
the tree as bisectable as possible.

Otherwise e.g. if I submitted patch + fixup + fixup + revert + fixup etc.
everyone doing a bisect would go crazy or rather hit many points
with various subtle breakages.


Why would you care about the merge and not about the individual 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". The completely merged tree is not tested
well [1] in both cases (unless after some time of course) as far as I can see,
no difference.

[1] I do some basic testing as in building and test booting on a few
machines on each merge, so calling it completely untested is not

So when I do a rebase versus Linus doing a merge (end result
the same code base) how is that more untested?


Sorry I still don't see the difference. AFAIK the only difference
is that I do the merge vs Linus doing it and that it looks slightly
different in the history, but apart from that (as in what
actually ends up in the source tree) it's all the same.

-Andi


--

[ message continues ]

No.

"git bisect" is perfetly able to handle merges. They are _fine_.

The problem with rebasing is that it *changes* something that was already 
tested (and possibly merged into somebody elses tree) into SOMETHING ELSE.

And that means that a large portion of the previous testing is basically 
thrown away.

In particular, if something worked for somebody before, it also removes 
the "known good state" from a bisection standpoint, so rebasing actually 
makes things _harder_ to bisect - because now you cannot sanely bisect 
between two versions of the tree (when you mark the old tree "good", it 
has no relevance to the new tree that had all the old history rewritten).

So no, rebasing does _not_ make bisection easier. It makes it easier to 
understand, perhaps, but it actually makes many things much much harder, 
and removes all trace of any testing coverage that the old commit had.

			Linus
--

[ message continues ]

The issue I worry about is it hitting between changes and their fixup.

e.g. for example if I find that specific change doesn't compile in some special
configuration then I amend it to fix that. Alternatively I could put in a fixup
commit  afterwards, but then if someone did bisect and the bisect hit inbetween
the change and the fixup they might end up with a tree that doesn't compile.

-Andi
--

[ message continues ]

Let me do a made-up example of this just to kind of illustrate the point.

Let's say that _I_ rebased history to always make it linear.

That would obviously make things much "easier" to bisect, since now it's 
just a linear list of commits, and bisection is just taking the midpoint 
of that list and trying it. Right? Also, I'd fix up the linear list so 
that any found bugs are squashed into th code that caused them, so all 
_known_ bugs are non-issues from the standpoint of bisection: because the 
code you are bisecting already has those removed entirely.

That's a clean nice linear history with no unnecessary breakages (no 
compile failures, no other unrelated and solved bugs) for bisection, so 
bisecting new bugs must be much simpler, right?

WRONG.

It means that a person who ran my tree as of yesterday, and had a working 
setup, but then updated to my tree as of today, and things break, can no 
longer bisect sanely AT ALL - because the state that he was at yesterday 
is basically completely *gone*, because it has been cleaned-up and 
sanitized, since I happened to rewrite history from a week ago due to 
finding a bug.

Also, related to the same thing, if that person had some patches of his 
own that he was working on on top of the state I had yesterday, since I 
rebased, it's now almost impossible for him to be able to judge what is 
really _new_ stuff, and what is just the old stuff he was working on, 
except it's been cleaned up and sanitized.

But at the same time, the new history is clearly _simpler_, isn't it? Yes, 
it is simpler, BUT ONLY IF YOU DON'T TAKE INTO ACCOUNT THAT SOMEBODY 
ALREADY SAW AND USED THE _OTHER_ HISTORY YESTERDAY!

I'm shouting, because this is really really important from a very 
fundamental standpoint. It's not just important from a git standpoint: 
this really is _not_ some odd git-specific implementation issue. No, it's 
much much more fundamental than git. It's a very basic fact that woudl be 
true with _any_ SCM.

So git just ...
[ message continues ]

One final note on this: the above is obviously not a problem for simple 
code that only really does one thing, and in particular for code that you 
wrote yourself. Moving your own commits around to make them make more 
sense - or splitting them up etc - is often a _good_ thing, even if it 
obviously does change history.

So using rebase to clean up and simplify and/or fix up stupid ordering 
issues is good, and "git rebase -i" is actually really good for this 
thing.

No, the problems start happening when you do it on a larger scale, or (and 
this is very common in the kernel), your rebase _moves_ the commits over 
big distances because you update to the top of my development tree. In 
that case, while your patches themselves may not have changed, the base 
that you based them on may have changed really subtly - it still compiles, 
it still "works", but maybe it doesn't work as well as it used to. And 
that's why the old testing you did is basically almost worthless.

So rebasing can be good or bad. It's a matter of degree. Rebasing private 
and small things is generally good. Rebasing bigger things can cause 
problems. And the further away you rebase something, the more problems it 
will generally cause. 

		Linus
--

[ message continues ]

You seem to be talking of subtly different things Andi and you, and
since I'm quite interested in the answer I'll try to rephrase what I
understood.

You say "don't rebase on the most recent kernel version".  Andi seems
to accept that going forwards.  You say "use topic branches that are
based on whatever kernel version you had at the time, I'll do the
merge".  That's ok too.  His remaining question is "what do I do with
broken patches _in_the_topic_branch_?".  He wants to
amend/merge/split/reorder within the topic branch so that the branch
itself is bisectable.  So what should be done there?

  OG.

--

[ message continues ]

If the patches have problems, then make a new topic branch and redo
them there, or reorder, amend, squash, whatever inside the original
branch. The problem comes once you open that branch out for other
people to pull from, or if that branch had pulled patches from someone
else. At that point you're destroying the history that other people
are now already sharing, in a meta-data sense (changing the sha1), as
well as invalidating whatever test points that people may have had on
those commits.

In short, don't rewrite public history. If you want to share out your
works-in-progress, just let people know that those branches of yours
are volatile and not to be trusted. But you can't pull someone else's
public history, and then make it volatile; subtle trouble ensues.
--

[ message continues ]

Ok I understand this applies to your tree because you have lots of direct users.
And also people tend to only submit patches to you which are relatively
well tested already and don't really do "raw development" in your tree.

But for people lower down the food chain that's not necessarily the
case. They usually only get some testing through -mm/linux-next
and perhaps occasionally for individual patches posted to verify
bugs. They tend to not have many people directly pulling their stuff
(and if it's someone it is some downstream developer who typically can deal
with an occasional rebase)

Anyways if you prefer I can send to you the raw development history
(with all reverts, fixups, non bisectable section etc.), but I suspect
you wouldn't really be very happy with that.

-Andi
--

[ message continues ]

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

Surely you agree that more testing is better? A rebased patch has had

Andi, no offense was intended here. I'm just asking you to walk

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".

Maybe the merging is trivial in all the cases you've hit so far,

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.
--

[ message continues ]

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

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

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,

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 ...
[ message continues ]

Andi,

say you create patch P1 against tree version T1 creating tree T2

you then rebase patch P1 against tree version T5 creating tree T6

people tested tree T2, they didn't test tree T6. while the changes made by 
patch P1 are still the same, there may be other changes that interact with 
things (and not nessasarily by chnaging the same area of the code, they 
may change memory layouts, timing, etc)

when someone is trying to track things down they can no longer recreate 
the state of tree T2, you've wiped the record of that from history. all 
they can do is to test version T5 and T6.

the other approach is that you create patch P1 against tree version T1 
creating tree T2, this then gets merged with tree version T5 upstream 
creating tree T6.

now when someone goes to track down a problem they can see all four tree 
versions, T1, T2, T5, and T6. they can not only test that T5 works but T6 
doesn't, but they can test that T2 works as well. They then can immediatly 
start looking for other interactions that are the result of the merge (and 
what's different between T1 and T5) rather then focusing just on 'what did 
patch P1 change'


now, it's also not good to have large areas of non-bisectable trees and 
bugs with their fixes a lot later, but with distributed testing and 
development you will never completely eliminate this.

there are things that you can do to minimize that, and using some number 
of topic branches seems to be one of the big ones (and I'll point you at 
the other explinations from this thread that have focused on what those 
are)

David Lang
--

[ message continues ]