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 PNP_IRQ_NR
PNP: rename pnp_register_*_resource() local variables
PNP: support optional IRQ resources
PNP: remove extra 0x100 bit from option priority
ISAPNP: handle independent options following dependent ones
PNP: convert resource options to single linked list
PNP: avoid legacy IDE IRQs
PNPACPI: add support for HP vendor-specific CCSR descriptors
ACPI: use dev_printk when possible
Bob Moore (17):
Make GPE disable more robust
ACPICA: Add argument count checking to control method invocation via acpi_evaluate_object
ACPICA: Fix for hang on GPE method invocation
ACPICA: Fix possible negative array index in acpi_ut_validate_exception
ACPICA: Eliminate acpi_native_uint type v2
ACPICA: Removed unused include files from source files
ACPICA: Several lint changes, no functional changes
ACPICA: Add const qualifier for appropriate string constants
ACPICA: Update version to 20080514
ACPICA: Workaround for reversed _PRT entries from BIOS
ACPICA: Update DMAR and SRAT table definitions
ACPICA: Update disassembler for DMAR table changes
ACPICA: Fix for invalid large array index on 64-bit systems
ACPICA: Cleanup debug operand dump mechanism
ACPICA: Cleanup of _PRT parsing code
ACPICA: Fix mutex debug code for wrong loop termination value
ACPICA: Update version to 20080609
Carlos Corbacho (7):
acer-wmi: Remove LED colour comment from documentation
acer-wmi: Blacklist backlight on Acer Aspire 1520 & 1360 series
acer-wmi: Respect framebuffer blanking in backlight
acer-wmi: Add EC quirk for Fujitsu Siemens Amilo Li 1718
acer-wmi: Disable device autodetection on Fujitsu Siemens Amilo Li2732
acer-wmi: Add debugfs file for device detection
acer-wmi: Remove version number
Cezary Jackiewicz (2):
misc,acpi,backlight: compal Laptop Extras
compal-laptop: remove unnecessary lcd_level attribute
David Brownell (1):
ACPI PM: acpi_pm_device_sleep_state() cleanup
Jan Beulich (2):
ACPICA: Update tracking macros to reduce code/data size
Fix FADT parsing
Johannes Berg (1):
APM emulation: Notify about all suspend events, not just APM invoked ones (v2)
Jonathan Woithe (1):
Fujitsu-laptop update
Julia Jomantaite (1):
ACPI: video: fix brightness allocation
Len Brown (3):
dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled.
ACPI: Zhang Rui maintains ACPI THERMAL and FAN
ACPI: Andi Kleen maintains the ACPI sub-system
Mike Travis (1):
ACPI: change processors from array to per_cpu variable
Rafael J. Wysocki (4):
PCI ACPI: Drop the second argument of platform_pci_choose_state
ACPI PM: Remove obsolete Toshiba workaround
Freezer: Introduce PF_FREEZER_NOSIG
snapshot: Use pm_mutex for mutual exclusion
Randy Dunlap (2):
acpi: fix printk format warning
fujitsu-laptop: depends on INPUT
Vegard Nossum (2):
ACPICA: fix mutex names in debug code.
ACPI: don't walk tables if ACPI was disabled
Yi Yang (2):
ACPI: fix acpi fan state set error
ACPI: fix processor throttling set error
Zhang Rui (4):
fix a deadlock issue when poking "eject" file
force offline the processor during hot-removal
create sysfs link from acpi device to sysdev for cpu
ACPI: Enhance /sys/firmware/interrupts to allow enable/disable/clear from user-space
Zhao Yakui (4):
ACPI: Disable the C2C3_FFH access mode HW has no MWAIT support
ACPI: Create "idle=halt" bootparam
ACPI : Create "idle=nomwait" bootparam
ACPI: Disable MWAIT via DMI on broken Compal board
Documentation/ABI/testing/sysfs-firmware-acpi | 127 +++--
Documentation/kernel-parameters.txt | 5 +-
Documentation/laptops/acer-wmi.txt | 2 -
MAINTAINERS | 25 +-
arch/ia64/kernel/process.c | 4 +
arch/x86/kernel/acpi/processor.c | 6 +
arch/x86/kernel/process.c | 28 +-
arch/x86/mm/srat_32.c | 3 +-
drivers/acpi/Makefile | 2 +-
drivers/acpi/bay.c | 3 +
drivers/acpi/bus.c | 2 +-
drivers/acpi/dispatcher/dsinit.c | 2 +-
drivers/acpi/dispatcher/dsmethod.c | 1 -
drivers/acpi/dispatcher/dsopcode.c | 22 +-
drivers/acpi/dispatcher/dswexec.c | 8 -
drivers/acpi/dispatcher/dswstate.c | 20 +-
drivers/acpi/dock.c | 3 +
drivers/acpi/events/evevent.c | 6 +-
drivers/acpi/events/evgpe.c | 36 +-
drivers/acpi/events/evgpeblk.c | 18 +-
drivers/acpi/events/evmisc.c | 4 +-
drivers/acpi/events/evregion.c | 5 +-
drivers/acpi/events/evrgnini.c | 2 +-
drivers/acpi/events/evxfevnt.c | 18 +-
drivers/acpi/executer/exconfig.c | 17 +-
drivers/acpi/executer/exconvrt.c | 12 +-
drivers/acpi/executer/excreate.c | 2 -
drivers/acpi/executer/exdump.c | 67 +--
drivers/acpi/executer/exfldio.c | 9 +-
drivers/acpi/executer/exmisc.c | 8 +-
drivers/acpi/executer/exprep.c | 8 +-
drivers/acpi/executer/exregion.c | 2 +-
drivers/acpi/executer/exresop.c | 4 +
drivers/acpi/executer/exstore.c | 6 -
drivers/acpi/fan.c | 8 +-
drivers/acpi/glue.c | 3 +
drivers/acpi/hardware/hwgpe.c | 52 ++-
drivers/acpi/namespace/nsdump.c | 6 +-
drivers/acpi/namespace/nseval.c | 35 +
drivers/acpi/namespace/nsinit.c | 1 -
drivers/acpi/namespace/nsload.c | 3 +-
drivers/acpi/namespace/nsparse.c | 15 +-
drivers/acpi/namespace/nsutils.c | 50 +-
drivers/acpi/namespace/nsxfeval.c | 3 +-
drivers/acpi/numa.c | 4 +-
drivers/acpi/parser/psargs.c | 4 +-
drivers/acpi/parser/psxface.c | 4 +-
drivers/acpi/pci_irq.c | 38 +-
drivers/acpi/processor_core.c | 75 ++-
drivers/acpi/processor_idle.c | 34 +-
drivers/acpi/processor_perflib.c | 18 +-
drivers/acpi/processor_throttling.c | 38 +-
drivers/acpi/reboot.c | 50 ++
drivers/acpi/resources/rscalc.c | 4 +-
drivers/acpi/resources/rscreate.c | 41 +-
drivers/acpi/resources/rsmisc.c | 2 +-
drivers/acpi/resources/rsutils.c | 13 +-
drivers/acpi/scan.c | 62 ++-
drivers/acpi/sleep/main.c | 39 +-
drivers/acpi/system.c | 169 +++++-
drivers/acpi/tables/tbfadt.c | 23 +-
drivers/acpi/tables/tbfind.c | 5 +-
drivers/acpi/tables/tbinstal.c | 30 +-
drivers/acpi/tables/tbutils.c | 15 +-
drivers/acpi/tables/tbxface.c | 28 +-
drivers/acpi/tables/tbxfroot.c | 4 +-
drivers/acpi/utilities/utalloc.c | 5 +-
drivers/acpi/utilities/utcopy.c | 4 +-
drivers/acpi/utilities/utdebug.c | 54 +-
drivers/acpi/utilities/utdelete.c | 2 +-
drivers/acpi/utilities/uteval.c | 5 +-
drivers/acpi/utilities/utmisc.c | 39 +-
drivers/acpi/utilities/utmutex.c | 4 +-
drivers/acpi/utilities/utobject.c | 9 +-
drivers/acpi/video.c | 123 +++--
drivers/char/apm-emulation.c | 346 +++++++-----
drivers/misc/Kconfig | 31 +-
drivers/misc/Makefile | 5 +-
drivers/misc/acer-wmi.c | 145 ++++-
drivers/misc/compal-laptop.c | 404 ++++++++++++
drivers/misc/eeepc-laptop.c | 4 +-
drivers/misc/fujitsu-laptop.c | 825 +++++++++++++++++++++++--
drivers/pci/pci-acpi.c | 6 +-
drivers/pci/pci.c | 4 +-
drivers/pci/pci.h | 3 +-
drivers/pnp/base.h | 148 ++++-
drivers/pnp/core.c | 29 +-
drivers/pnp/interface.c | 207 +++----
drivers/pnp/isapnp/core.c | 253 +++-----
drivers/pnp/manager.c | 414 ++++---------
drivers/pnp/pnpacpi/core.c | 4 +-
drivers/pnp/pnpacpi/rsparser.c | 492 +++++++++------
drivers/pnp/pnpbios/rsparser.c | 274 +++++----
drivers/pnp/quirks.c | 307 +++++-----
drivers/pnp/resource.c | 454 ++++++--------
drivers/pnp/support.c | 171 +++++-
drivers/pnp/system.c | 4 +-
drivers/serial/8250_pnp.c | 24 +-
include/acpi/acconfig.h | 2 +-
include/acpi/acdisasm.h | 1 +
include/acpi/acdispat.h | 2 +-
include/acpi/acexcep.h | 10 +-
include/acpi/acglobal.h | 2 +-
include/acpi/achware.h | 4 +-
include/acpi/acinterp.h | 5 +-
include/acpi/aclocal.h | 6 +-
include/acpi/acmacros.h | 38 +-
include/acpi/acnamesp.h | 30 +-
include/acpi/acpi_bus.h | 4 +-
include/acpi/acpiosxf.h | 2 +-
include/acpi/acpixf.h | 12 +-
include/acpi/acstruct.h | 10 +-
include/acpi/actables.h | 27 +-
include/acpi/actbl1.h | 23 +-
include/acpi/actypes.h | 16 +-
include/acpi/acutils.h | 70 ++-
include/acpi/processor.h | 2 +-
include/acpi/reboot.h | 14 +-
include/asm-ia64/processor.h | 2 +
include/asm-x86/processor.h | 2 +
include/linux/freezer.h | 10 +
include/linux/ioport.h | 5 +
include/linux/pnp.h | 146 +++--
include/linux/sched.h | 1 +
kernel/cpu.c | 1 +
kernel/kthread.c | 2 +-
kernel/power/process.c | 97 ++--
kernel/power/user.c | 71 ++-
128 files changed, 4330 insertions(+), 2449 deletions(-)
create mode 100644 drivers/acpi/reboot.c
create mode 100644 drivers/misc/compal-laptop.c
On Wednesday, 16 of July 2008, Andi Kleen wrote:
>
> 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.
Well, IMO it would be better to merge PCI first.
Thanks,
Rafael
On Wednesday, July 16, 2008 3:11 pm Rafael J. Wysocki wrote:
> On Wednesday, 16 of July 2008, Andi Kleen wrote:
> > 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.
>
> Well, IMO it would be better to merge PCI first.
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
On Wed, 16 Jul 2008, Jesse Barnes wrote:
>
> Yeah, they're interdependent (I pulled from Len's tree, hopefully Andi
> preserved the changesets).
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
On Wednesday, July 16, 2008 4:45 pm Linus Torvalds wrote:
> On Wed, 16 Jul 2008, Jesse Barnes wrote:
> > Yeah, they're interdependent (I pulled from Len's tree, hopefully Andi
> > preserved the changesets).
>
> Andi did not. The whole series I pulled was rebased today at 2PM.
Ugg, when Andi took over we talked about it; I thought we had agreed that he
would stick with Len's tree. I guess I was wrong.
> 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.
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
On Wed, 16 Jul 2008, Jesse Barnes wrote:
> >
> > Andi did not. The whole series I pulled was rebased today at 2PM.
>
> Ugg, when Andi took over we talked about it; I thought we had agreed that he
> would stick with Len's tree. I guess I was wrong.
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
shouldn't judge before I'm sure.
> 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. :)
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
On Wed, 16 Jul 2008, Linus Torvalds wrote:
>
> 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
> shouldn't judge before I'm sure.
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
On Wednesday, July 16, 2008 5:53:55 pm Linus Torvalds wrote:
> On Wed, 16 Jul 2008, Linus Torvalds wrote:
> > 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
> > shouldn't judge before I'm sure.
>
> No, he rebased it - the three commits you shared are now separate ones.
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
coordinate better next time.
> 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?
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
On Wed, 16 Jul 2008, Jesse Barnes wrote:
>
> 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
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 reason. They do their filesystem. They seldom have issues that
crop up on just certain platforms etc.
- And more importantly - play around with it. Get used to it first. Look
at what other people do. Start small, with perhaps just one special
topic branch to test the waters with.
So don't worry _too_ much.
Linus
Linus Torvalds wrote:
>
> On Wed, 16 Jul 2008, Jesse Barnes wrote:
>> Yeah, they're interdependent (I pulled from Len's tree, hopefully Andi
>> preserved the changesets).
>
> 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.
I went back to quilt because the topic branches didn't really
work out for me.
> 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.
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
Linus Torvalds wrote:
>
> On Wed, 16 Jul 2008, Jesse Barnes wrote:
>>> Andi did not. The whole series I pulled was rebased today at 2PM.
>> Ugg, when Andi took over we talked about it; I thought we had agreed that he
>> would stick with Len's tree. I guess I was wrong.
>
> 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
> shouldn't judge before I'm sure.
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
Jesse Barnes wrote:
> On Wednesday, July 16, 2008 3:11 pm Rafael J. Wysocki wrote:
>> On Wednesday, 16 of July 2008, Andi Kleen wrote:
>>> 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.
>> Well, IMO it would be better to merge PCI first.
>
> 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.
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
On Thu, 17 Jul 2008, Andi Kleen wrote:
>
> 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.
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
On Thu, 17 Jul 2008, Andi Kleen wrote:
>
> 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.
That still doesn't excuse then breaking _other_ peoples work.
> 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.
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
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
On Thu, 17 Jul 2008, Linus Torvalds wrote:
>
> 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.
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 people
involved have been doing their own development without having the rug
pulled out from them all the time by using a different kernel as a base.
Linus
(*) Which is happily fairly rare these days! I obviously detest the
complexity that is ACPI, but even if I detest it, Intel should get cudos
for getting it to work.
On Thu, 17 Jul 2008, Linus Torvalds wrote:
>
> 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).
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 ignored the ACPI case too.
Linus
Linus Torvalds wrote:
>
> On Thu, 17 Jul 2008, Linus Torvalds wrote:
>> 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.
>
> 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.
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
that easier.
> 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.
Well, at least for this summer the ACPI tree will have some Andi flavor.
> 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.
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,
can't it?
>
> 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".
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.
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-branches
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 sometimes people want to test them, but only
against a recent baseline.
Branches pulled into "release" for linus are frozen,
or course, since Linus' tree is permanent history.
So any reverts/updates after that point have to
be real revert commits and incremental patches.
cheers,
-Len
ps.
One thing I wish I had in git is a way to make this sequence easier...
Say I have a big topic branch with 30 patches in it.
The 3rd patch turns out to have a bug in it, but the
rest of the series is okay. Today I invoke gitk on
the branch and keep that open.
Then I create a new topic branch at the broken patch.
I always consult ~/src/git/Documentation/git-reset.txt
so I can remember the following sequence...
$ git reset --soft HEAD^
$ edit
$ git commit -a -c ORIG_HEAD
Now I've got the fixed 3rd patch checked in,
but 27 patches in the original branch are hanging
off the original broken 3rd patch.
So I git-cherry-pick 27 patches
I hope I get them in the right order and don't miss any...
It would be nice if we could somehow git rebase those
27 patches in a single command, but if we do,
that pulls with it the broken 3rd patch.
come to think of it, I can probably export 4..27 as
an mbox and then import it on top of the new 3,
maybe that is what others do.
On Thu, Jul 17, 2008 at 9:23 AM, Andi Kleen <[email protected]> wrote:
> Linus Torvalds wrote:
>> 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.
>
> 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,
> can't it?
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.
On Thu, 2008-07-17 at 14:49 -0400, Len Brown wrote:
> Andi, Jesse, Linus,
>
> One thing I wish I had in git is a way to make this sequence easier...
>
> Say I have a big topic branch with 30 patches in it.
> The 3rd patch turns out to have a bug in it, but the
> rest of the series is okay. Today I invoke gitk on
> the branch and keep that open.
> Then I create a new topic branch at the broken patch.
>
> I always consult ~/src/git/Documentation/git-reset.txt
> so I can remember the following sequence...
>
> $ git reset --soft HEAD^
> $ edit
> $ git commit -a -c ORIG_HEAD
>
> Now I've got the fixed 3rd patch checked in,
> but 27 patches in the original branch are hanging
> off the original broken 3rd patch.
> So I git-cherry-pick 27 patches
> I hope I get them in the right order and don't miss any...
>
> It would be nice if we could somehow git rebase those
> 27 patches in a single command, but if we do,
> that pulls with it the broken 3rd patch.
git rebase --interactive
sounds like exactly what you are asking for.
Harvey
On Thu, 17 Jul 2008, Len Brown wrote:
>
> ps.
>
> One thing I wish I had in git is a way to make this sequence easier...
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
git way" actually much more understandable:
> Say I have a big topic branch with 30 patches in it.
> The 3rd patch turns out to have a bug in it, but the
> rest of the series is okay. Today I invoke gitk on
> the branch and keep that open.
>
> Then I create a new topic branch at the broken patch.
>
> I always consult ~/src/git/Documentation/git-reset.txt
> so I can remember the following sequence...
>
> $ git reset --soft HEAD^
> $ edit
> $ git commit -a -c ORIG_HEAD
>
> Now I've got the fixed 3rd patch checked in,
> but 27 patches in the original branch are hanging
> off the original broken 3rd patch.
> So I git-cherry-pick 27 patches
> I hope I get them in the right order and don't miss any...
>
> It would be nice if we could somehow git rebase those
> 27 patches in a single command, but if we do,
> that pulls with it the broken 3rd patch.
>
> come to think of it, I can probably export 4..27 as
> an mbox and then import it on top of the new 3,
> maybe that is what others do.
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 the bigger reason is that obviously all the commits I tend to do are
just merges, and I don't maintain "patch series" in my trees except
sometimes for git itself ]
Git rebase can also try to rebase merges (the "-p" flag - short form of
"--preserve-merges"), so this _does_ work with a non-linear history too to
some degree, but quite frankly, I would seriously suggest people try to
avoid getting quite that funky with it. It's useful for emergencies, but
you'd better know what you are doing, and you should look at the
before-and-after state very carefully.
Linus
On Thu, 17 Jul 2008, Linus Torvalds wrote:
>
> No, what others do (if they know the tricks) is to say something like:
>
> git rebase -i <starting-point>
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
> It matters to us end-testers when we do a git bisect. If you leave the
> history intact
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.
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.
Why would you care about the merge and not about the individual patches?
Note that these quilt merges don't have conflicts.
> 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". 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
true.
> 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?
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.
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
Harvey Harrison wrote:
> git rebase --interactive
>
> sounds like exactly what you are asking for.
Sounds like a nice feature. Thanks for the pointer.
-Andi
On Thu, 17 Jul 2008, Andi Kleen wrote:
>
> The whole point of the exercise of cleaning up/rewriting the history is to make
> the tree as bisectable as possible.
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
On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <[email protected]> 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?
>> 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.
> 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
> true.
Andi, no offense was intended here. I'm just asking you to walk
through a thought experiment with me, okay?
>> 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".
Maybe the merging is trivial in all the cases you've hit so far,
great. What happens when it isn't? That's the larger point here.
>> 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.
>
> 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.
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.
Linus Torvalds wrote:
> On Thu, 17 Jul 2008, Andi Kleen wrote:
>> The whole point of the exercise of cleaning up/rewriting the history is to make
>> the tree as bisectable as possible.
>
> No.
>
> "git bisect" is perfetly able to handle merges. They are _fine_.
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
On Thu, 17 Jul 2008, Linus Torvalds wrote:
>
> 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).
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 happens to encode that fundamental truth a bit more explicitly
and make it very obvious. Git is very careful at _not_ losing that state
as it existed somewhere yesterday.
So rebasing and cleanups may indeed result in a "simpler" history, but it
only look that way if you then ignore all the _other_ "simpler" histories.
So anybody who rebases basically creates not just one simple history, but
a _many_ "simple" histories, and in doing so actually creates a
potentially much bigger mess than he started out with!
As long as you never _ever_ expose your rewriting of history to anybody
else, people won't notice or care, because you basically guarantee that
nobody can ever see all those _other_ "simpler" histories, and they only
see the one final result. That's why 'rebase' is useful for private
histories.
But even then, any testing you did in your private tree is now suspect,
because that testing was done with the old history that you threw away.
So even if you delete all the old histories and never show them, they kind
of do exist conceptually - they existed in the sense that you tested them,
and you've just hidden the fact that what you release is different from
what you tested.
Linus
On Thu, 17 Jul 2008, Linus Torvalds wrote:
>
> But even then, any testing you did in your private tree is now suspect,
> because that testing was done with the old history that you threw away.
> So even if you delete all the old histories and never show them, they kind
> of do exist conceptually - they existed in the sense that you tested them,
> and you've just hidden the fact that what you release is different from
> what you tested.
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
Ray Lee wrote:
> On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <[email protected]> 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
>
> It means that a person who ran my tree as of yesterday,
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
On Thu, Jul 17, 2008 at 02:49:04PM -0400, Len Brown wrote:
> One thing I wish I had in git is a way to make this sequence easier...
Linus's answer (with rebase -i) is probably better, but my habit is to
do what you describe, with some minor shortcuts:
> Say I have a big topic branch with 30 patches in it.
> The 3rd patch turns out to have a bug in it, but the
> rest of the series is okay. Today I invoke gitk on
> the branch and keep that open.
> Then I create a new topic branch at the broken patch.
>
> I always consult ~/src/git/Documentation/git-reset.txt
> so I can remember the following sequence...
>
> $ git reset --soft HEAD^
> $ edit
> $ git commit -a -c ORIG_HEAD
Instead of the above three steps, you can do just:
$ edit
$ git commit -a --amend
> Now I've got the fixed 3rd patch checked in,
> but 27 patches in the original branch are hanging
> off the original broken 3rd patch.
> So I git-cherry-pick 27 patches
> I hope I get them in the right order and don't miss any...
>
> It would be nice if we could somehow git rebase those
> 27 patches in a single command, but if we do,
> that pulls with it the broken 3rd patch.
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
just created, and replaces the named branch with the result.
> come to think of it, I can probably export 4..27 as
> an mbox and then import it on top of the new 3,
> maybe that is what others do.
That works too.
--b.
On Thu, 17 Jul 2008, Linus Torvalds wrote:
> On Thu, 17 Jul 2008, Andi Kleen wrote:
> >
> > 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.
>
> 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.
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Andi Kleen <[email protected]>
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 <[email protected]>
commit 816c2eda3ce8fa7eb62f22e01e2ec7a3f7d677c0
dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled.
was merged between 2.6.26-rc8 and -rc9)
Due to rebasing the ACPI tree via quilt the same patch got applied
again via
commit cc7e51666d82aedfd6b9a033ca1a10d71c21f1ca
dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled.
Revert it, as it is obviously bogus.
Signed-off-by: Thomas Gleixner <[email protected]>
---
diff --git a/drivers/acpi/bay.c b/drivers/acpi/bay.c
index e6caf5d..61b6c5b 100644
--- a/drivers/acpi/bay.c
+++ b/drivers/acpi/bay.c
@@ -380,9 +380,6 @@ 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 1e872e7..bb7c51f 100644
--- a/drivers/acpi/dock.c
+++ b/drivers/acpi/dock.c
@@ -920,9 +920,6 @@ 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);
> Please revert the one I happened to notice. Patch below.
Good catch. Thanks. I'll queue a revert.
-Andi
On Fri, 18 Jul 2008, Thomas Gleixner wrote:
>
> Please revert the one I happened to notice. Patch below.
Another one.
Thanks,
tglx
----------->
Subject: APCI: revert another duplicated patch
From: Thomas Gleixner <[email protected]>
commit d1857056904d5f313f11184fcfa624652ff9620a
is another superfluous duplicate commit caused by
git -> quilt -> git conversion.
Revert it.
Signed-off-by: Thomas Gleixner <[email protected]>
---
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;
On Thu, 17 Jul 2008, Andi Kleen wrote:
> Ray Lee wrote:
>> On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <[email protected]> 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.
>
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
On Thu, Jul 17, 2008 at 01:28:20PM -0700, Linus Torvalds wrote:
> 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.
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.
On Fri, Jul 18, 2008 at 6:25 AM, Olivier Galibert <[email protected]> wrote:
> 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?
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.