I got a spitz recently which moved 2.6 for it forwards a lot. Have a look at:

http://www.rpsys.net/openzaurus/

This file should give you an idea of which patches to apply in what order: http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.14-rc1.bb

With my patch series applied, we're missing usb client (usb host works) and sound support.

Mainline is missing power management and currently fails to compile without my patch series but I'm working on that.

I'm no sure offical preview images exist but here's something I built myself recently:

http://www.rpsys.net/openzaurus/temp/spitz/

Rename the gpe or opie file "hdimage1.tgz" to flash depending on what flavoured image you'd like. You need the other files including gnu-tar. You don't need an initrd.bin file as under 2.6 we can boot directly from the microdrive.

I'm hoping these work - I'm not sure I've tried one of them... :)

I'm open to any help in getting the none ipaq/tosa things merged with mainline. Have a look through them patch series and see if there's anything you fancy taking on. Most of them are simple fixes although some are nasty hacks we need to find some way of doing nicely.

The biggest thing is the battery/power management patch. I've just agreed some changes to enable it to stand a chance of making mainline. It probably needs more coding style cleanup.

There's also sound to get working although so code arrived yesterday which should help with that. The usb client code exists in handheld.org's kernel26 cvs tree. We need to extract it, fix any bugs and talk to the usb developers about it.

Its a shame you don't have a C1000 as there's a nasty bit of coding someone with such a device needs to do to complete mainline 2.6 support (I2C driver for its IO Expander to enable access to its extra GPIOs).

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc4/2.6.14-rc4-mm1/

• Lots of i2c, PCI and USB updates
• Large input layer update to convert it all to dynamic input_dev allocation
• Significant x86_64 updates
• MD updates
• Lots of core memory management scalability rework

This is a request for testers for ntfs. 2.6.14-rc4-mm1 contains a pretty much complete re-write of file write support so some more testers than just myself would be good before I submit it for inclusion in 2.6.15...

The rewrite means that the following features are now supported:

Given an existing uncompressed and unencrypted file, you can use:

• write(2) to write to the file, including beyond the end of the existing file, and the file will be extended appropriately. Both resident and non-resident files are supported. Support for heavily fragmented files still has some limitations but you will just get an EOPNOTSUPP error if you hit one. Everything will still be consistent on the volume. Sparse files can also be written to and holes will be filled in appropriately.
• truncate(2) and ftruncate(2) to change the size of the file, inlcuding using open(2) with O_TRUNC flag. As with write(2) there still are some limitations for heavily fragmented files, and as above, everything will still be consistent on the volume if you hit an unsupported case.

What this means is that you can now run your favourite editor on an existing file, e.g. "vim /ntfs/somefile.txt" works fine and you can save your changes. Also things like running OpenOffice should work to edit existing MS Office documents but I haven't tried it yet (it should work as long as OpenOffice does not need to create temporary files in the same directory as the document).

Still not supported features are creation/deletion of files/directories and mmap(2) based writes to sparse regions of files. (The mmap(2) support has not been modified since the last release, only the file write(2) support was rewritten.)

If you do try it, please let me know how it worked for you! - Thanks a lot in advance for testing!

You should be able to hopefully fix windows by booting with the installation CD and going into recovery console and running chkdsk on the partition. You can also try running ntfsfix from ntfsprogs and then booting into windows. This may be sufficient to allow it to do a chkdsk on the partition before it crashes.

I found a bug that caused corruption of the openoffice document as you described. The fix is below.

Sounds like I will be hosting a Git/Cogito tutorial in the upcoming LCA2006 (Dunedin, NZ, Jan 25~28). Given that I do have some significant holes in my git knowledge (no, really!?) I'll be happy if other git hackers/users are present at LCA and willing to take part in the tutorial.

Petr Baudis hinted earlier that he might be coming, as did Linus (but he was hoping for a sponsor, I'm not sure whether he'll be there or not). Speak up if you'll be there!

I'll post my slides and presentation plan beforehand to the list, to avoid spreading misinfirmation/bad practices. They will probably be based on a recent talk I gave @ Wellington Perl Mongers about swtiching to Git/Cogito:

http://wellington.pm.org/archive/200510/git/

The feedback (from both non-cogito-users and actual cogito-users) was that I made it sound too complicated, so the current plan is to focus on the tutorial part, and leave "under the hood" parts for a rainy day or for an after tutorial in-the-corridor chat.

I should not be saying this because I am the primary guilty party, but you should not be so impressed.

Being able to specify which merge strategy to use is a useful thing, but I do not think being able to try more than one merge strategies automatically, while it has some coolness value, is very useful in practice.

The language-specific or project-specific part should be made orthogonal to merge strategy modules, which currently is not. The primary thing Daniel's git-merge-resolve and Fredrik's git-merge-recursive do is to figure out which paths can be resolved without merging the file contents, and which paths need to be resolved with file contents merge, and they use different strategies to find which 3 variants of the contents to use for that final merge.

But at the end of the day, merging the contents is done by running 'merge' in either case. This should be made either customizable, or we ship our standard one that can be extended to first run 'file' to see the file content type of what is being merged and run content specific merge program if there is one.

Even if we did that, we are still doing 3-way merge; git-merge framework may not mesh very well when we want to use something like codeville merge which is not based on 3-way.

Oh, the git merge is about a million times better than any silly weave merge with extra BonusPoints and MagicCapitalizedNames.

Why? Because if you want to be slow and careful, you can always just create the weave after-the-fact and do a weave merge.

And because well-behaved git merges are so fast, you can actually afford to so so.

There's nothing magic in a weave merge. It's just a trick. It doesn't need the files to be in weave format beforehand, even though people seem to believe that file formats go together with it.

If somebody thinks a weave merge is wonderful and fixes everything, I have to rain on their parade. You still need to manually fix real conflicts up, and regardless, what kind of merge you do has _nothing_ to do with how you maintain your files.

If you want to do a weave merge inside git, then the way to do that is to just create the weave on demand in the (rare) case where it's needed. We have all the history. You might even just do a "lazy weave", which just starts from the common parent, and ignores the history before that.

Much cheaper that way, and arguably nicer (others will argue that you want to take history into account, to decide about undo's etc. It's a matter of taste).

The thing is, automatic merging isn't all _that_ important. The thing that made BK wonderful at merging was that it had a wonderful tool for merging for when there were real clashes, which is where the _really_ nasty cases are. The actual automatic merge wasn't necessarily anything magical.

(Same went for applying diffs, btw. What made BK nice was "renametool". Of course, it was also what made me decide that tracking renames was the wrong thing to do in the first place, but if you make a CMS that does renames, you'd better have a "renametool").

And if you have a tool that helps you visually merge the _real_ clashes, it doesn't much matter if you are only half-way decent on the automatic ones. They'll be so trivial that nobody cares.

And it doesn't matter _how_ good your automatic merges are, there always _will_ be real clashes.

[ Side note. Think about this for a while. Git did three-way merges pretty much since day one, but they only became _useful_ when we made it easy to see the merge conflicts and fix them up. That's a fundamental lesson right there: you don't have to be perfect, you have to make it easy for the user to fix up your imperfections. ]

So we should spend time on making it easy to see what the clash was, and on tools to help resolve them. Some random merge-strategy-of-the-day is just bling-bling.

The reason people like merge strategies is that it's a nice area for some mental masturbation. You can create all these fancy examples. And then can ignore the fact that most real merge problems end up being two people changing the same code in different ways, that just need manual merging.

Don't get me wrong - if somebody does a nice automated merge for git, it's a good thing, but it's probably much more important to try to integrate something like xxdiff to a git workflow. And _that_ level is probably where you want to have special language-based coloring etc to further help things out.

So keep your eyes on the ball. And "automatic merge" isn't it.

A three-way merge is plenty conservative for me.

Any merge will always get some case wrong, exactly the same way any merge will always get some that require fixing up, even if a human might say "that's a stupid merge". Two patches add the same thing to different places (an unsorted array of PCI ID's or whatever), and pretty much any merge ever will silently "mismerge" it as far as a human is concerned. From a _technical_ point it was correct. In practice, it wasn't.

So when I say "conservative", I don't mean "can never mis-merge", because such a thing doesn't exist. No, "conservative" means that it seldom does it in practice, and that when it happens, you can at least understand why it happened.

A simple strategy that makes people understand what happened is often much better than a more complex one. And you should never underestimate the importance of peoples _expectations_. A three-way merge has a _huge_ advantage in that absolutely tons of people are used to what it does: even when they don't necessarily "understand" the merge (they never cared), if they've worked with CVS they've seen them before.

Don't get me wrong - a weave merge is pretty damn conservative too. I'm not down on weave merges, I just don't think that the difference is that huge in practice - the difference between a three-way merge and a weave merge is much smaller than the advantage of a good graphical tool and a good workflow.

That's really my argument here: automated merges aren't the end-all. I realize that a lot of SCM people think that three-way merges are old and boring and stupid, but the fact is, sometimes the old ways aren't the best ways, but sometimes they are old just because they are good enough.

Yeah, I know I said -rc4 was going to be the last one, but as some of you may have noticed from the discussions, a day before I was planning on releasing 2.6.14 we found a couple of bugs (nasty RCU callback delays, swiotlb, etc). The fixes for those weren't all that complicated, but the problems were subtle enough that I wanted to get them fixed and have another -rc before final release.

So here it is. There's a number of other small random fixes in there too.

This is what the recent git-rev-list changes have all been gearing up for.

When we use a path filter to git-rev-list, the new "--dense" flag asks git-rev-list to compress the history so that it _only_ contains commits that change files in the path filter. It also rewrites the parent information so that tools like "gitk" will see the result as a dense history tree.

For example, on the current kernel archive:

        [torvalds@g5 linux]$ git-rev-list HEAD | wc -l
        9904
        [torvalds@g5 linux]$ git-rev-list HEAD -- kernel | wc -l
        5442
        [torvalds@g5 linux]$ git-rev-list --dense HEAD -- kernel | wc -l
        356

which shows that while we have almost ten thousand commits, we can prune down the work to slightly more than half by only following the merges that are interesting. But further, we can then compress the history to just 356 entries that actually make changes to the kernel subdirectory.

To see this in action, try something like

gitk --dense -- gitk

to see just the history that affects gitk. Or, to show that true parallel development still remains parallel, do

gitk --dense -- daemon.c

which shows some parallel commits in the current git tree.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---

I'm really happy with how this turned out. It's a bit expensive to run on big archives, but I _really_ think it's quite spectacular. And likely very useful indeed.

For example, say you love gitk, but only care about networking changes. Easy enough, just do

gitk --dense -- net/ include/net/

and off you go. It's not free (we do a _lot_ of tree comparisons), but dammit, it's fast enough that it's very very useful. The tree comparisons are done very efficiently.

This is _way_ more powerful than annotate. Interested in just a single file? Just do

gitk --dense -- kernel/exit.c

and it will show the 17 or so commits that change kernel/exit.c with the right history (it turns out that there is no parallel development at all in that file, so in this case it will linearize history entirely).

Damn, I'm good.

one additional point.

This took 0.91 seconds to complete on the current kernel history on my machine with a pretty much fully packed archive, and the memory footprint was a total of about 12MB.

And it scales pretty well too. On the historical linux archive, which is three years of history, the same thing takes me just over 12 seconds and 52MB, and that's for the _whole_ history. And it's not just following one file: it's following that subdirectory.

So it really is pretty damn cool.

Of course, I might have a bug somewhere, but it all _seems_ to work very well indeed.

Never. I'm 100% convinced that tracking renames is WRONG WRONG WRONG.

You can follow renames _afterwards_.

Git tracks contents. And I think we've proven that figuring out renames after-the-fact from those contents is not only doable, but very well supported already.

I'm convinced that git handles renames better than any other SCM ever. Exactly because we figure it out when it matters.

let's say that you want to follow a certain filename, what you can do is basically (fake shell syntax with "goto restart")

        rev=HEAD
   restart:

        git-rev-list $rev --dense --parents -- "$filename" |
                while read commit parent1 restofparents
                do
                        if [ "$restofparents" ]; then
                                .. it's a merge, do whatever it is you do
                                   with merges ..
                        else
                                shaold=$(git-ls-tree $parent -- "$filename")
                                shanew=$(git-ls-tree $commit -- "$filename")

                                # Did it disappear?
                                # Maybe it got renamed from something
                                if [ -z "$shaold" ]; then
                                        old=$(git-diff-tree -M -r $commit |
                                                grep " R .* $filename")
                                        echo "rename? $old"
                                        filename=figure-it-out-from-$old
                                        rev=$parent
                                        goto restart
                                fi
                                git-diff-tree -p $commit -- "$filename"
                        fi
                while

or something similar.

In other words: you'll basically have to figure out the renames on your own, and follow the renaming, but something like the above should do it.

The problem with renames isn't the straight-line case.

The problem with renames is the merge case. And quite frankly, I don't know how to handle that sanely.

If everything was straight-line (CVS), renames would be trivial. But git-rev-list very fundamentally works on something that isn't. So let's look at the _fundamental_ problem:

• git-rev-list traverses one commit at a time, and it doesn't even _know_ whether it has seem all the parents of that commit during the first phase.

  The first phase is the "limit_list()" thing, which is when we decide which commits are reachable, uninteresting, and which merges to follow.

  Now, think about this: since we don't even know that we've seen all parents, that pretty much by definition means that we can't know what has been renamed if we were to track it.

• in the second phase (which is where I do the densification), we do actually have the full tree and that makes a lot of things a lot easier to do. When it comes to dense, for example, it means that I know all the UNINTERESTING logic has already been done, and that all merges have been simplified.

  But in the second phase, we couldn't do rename detection either, since by then, we've already fixed the list of names as far as merges are concerned.

And note that this fundamental issue is true _whether_ we have some explicit rename information in a commit or not.

Git-rev-list has a few additional issues that make it even more interesting:

• git-rev-list fundamentally is designed for multiple heads. There is no one special "origin" head. We might not have _one_ end-point, we might have twenty-five different heads we're looking at at the same time. Try

  gitk --all --dense -d -- git-fetch.c

  on the current git archive, and be impressed by how well it works (and yes, you'll see a funny artifact: "--dense" never removes a line of development entirely, so you'll see a single dot for the two "unrelated" lines: "gitk" and "to-do" do not share a root with the rest of them. You'll get a single dot for that root, even if it obviously doesn't actually change "git-fetch.c").

  You'll also very clearly see the "Big tool rename" which created that name: it will be the first commit after the root that is visible that way.

• path limiters are fundamentally designed to take a list of paths and directories. Personally, I find that to be a lot more important than a single file. That's very efficient the way we do it, but if you were to _change_ the list of paths, you'd basically have to track those changes over history.

  (This actually happens even with a single path - imagine a merge, and a rename down one line of the merge. You'll have to keep track of different files for the different lines of development, and then when they join together, and the rename only happened in one of them, you'll have to make an executive decision, or just continue to track _both_)

So what do I propose? I propose that you realize that "git-rev-list" is just the _building_ block. It does one thing, and one thing only: it creates revision list.

A user basically _never_ uses git-rev-list directly: it just doesn't make sense. It's not what git-rev-list is there for. git-rev-list is meant to be used as a base for doing the real work. And that's how you can use it for renaming too.

If you think of "git-rev-list --dense -- name" as a fast way to get a set of commits that affect "name", suddenly it all makes sense. You suddenly realize that that's a nice building block for figuring out renames. It's not _all_ of it, but it's a big portion.

To go back to "gitk", let's see what the path limitation shows us. Right now, doing a

gitk --all --dense -d -- git-fetch.sh

only shows that particular name, and that's by design. Maybe that's what the user wants? You have to realize that especially if you remember an _old_ name that may not even exist any more, that's REALLY what you want. Something that works more like "annotate" is useless, because something that works like annotate would just say "I don't have that file, I can't follow renames" and exit.

So the first lesson to learn is that following just pure path-names is actually meaningful ON ITS OWN! Sometimes you do NOT want to follow renames.

For example, let's say that you used to work on git 4 months ago, but gave up, since it was too rough for you. But you played around with it, and now you're back, and you have an old patch that you want to re-apply, but it doesn't talk about "git-fetch.sh", it talks about "git-fetch-script". So you do

gitk --dense -- git-fetch-script

and voila, it does the right thing, and top of the thing is "Big tool rename", which tells you _exactly_ what happened to that PATHNAME.

See? Static pathnames are important!

Now, this does show that when you _do_ care about renames, "gitk" right now doesn't help you very much (no offense to gitk - how could it know that git-rev-list would give it pathname detection one day?). Let's go back to the original example, and see what we could do to make gitk more useful..

gitk --all --dense -d -- git-fetch.sh

Go and select that "Big tool rename" thing, and start looking for the rename..

You won't find it. Why? You'll see all-new files, no renames. It turns out that "gitk" follows the "parent" thing a bit _too_ slavishly, which is correct on one level, but in this case with "--dense" it turns out that what you want to do is see only what _that_ commit does, not what that commit did relative to its parent (which was the initial revision).

So while "--dense" made gitk work even without any changes, it's clear that the new capability means that gitk might want to have a new button: "show diff against 'fake parent'" and "show diff against 'real parent'".

If you want the global view, the default gitk behaviour is correct (it will show a "valid" diff - you'll see everything that changed between the points it shows). But in a rename-centric world, you want the _local_ change to that commit, and right now gitk can't show you that.

So for trackign renames, we probably want that as a helper to gitk.

Also, gitk has a "re-read references" button, but if you track renames, you probably want to do more than re-read them: you want to re-DO them with the "Big rename" as the new head (forget the old references entirely), and with the name list changed. New functionality (possibly you'd like to havea "New wiew" button, which actually starts a new gitk so that you can see both of them). Right now you'd have to do it by hand:

gitk --dense 215a7ad1ef790467a4cd3f0dcffbd6e5f04c38f7 -- git-fetch-script

(where 215a.. is the thing you get when you select the "Big tool rename")

You'd also probably like to have some way to limit the names shown for the git-diff-tree in gitk.

In short, the new "gitk --dense -- filename" doesn't help you nearly as much as it _could_. But when you squint a bit, I think you'll see how it's quite possible to do...

This patch is a rewrite of the one submitted on October 1st, using modules (http://marc.theaimsgroup.com/?l=linux-kernel&m=112819093522998&w=2).

This rewrite adds a tristate CONFIG_RCU_TORTURE_TEST, which enables an intense torture test of the RCU infratructure. This is needed due to the continued changes to the RCU infrastructure to accommodate dynamic ticks, CPU hotplug, realtime, and so on. Most of the code is in a separate file that is compiled only if the CONFIG variable is set. Documentation on how to run the test and interpret the output is also included.

This code has been tested on i386 and ppc64, and an earlier version of the code has received extensive testing on a number of architectures as part of the PREEMPT_RT patchset.

I wrote a low-level parallel port driver for the built-in port on SGI O2 (a.k.a. IP32).

The parallel port is driven by a standard ECP chipset, with memory-mapped I/O registers. That's why it was not possible to use the parport_pc module which assumes port-mapped I/O registers.

What works:

• Basic modes are supported: PCSPP, PS2.
• Compatibility mode with FIFO support is present.
• FIFO can be driven with or without interrupts.

What does not work:

• DMA support is not implemented (lack of documentation). If you have any information, please tell me.
• EPP and ECP modes are not implemented (lack of interest). I currently do not own any peripheral supporting this extended modes. It should not be too difficult to do.

All tests were done with an HP LaserJet 5MP connected to a R5000 SGI O2.

The module is named parport_ip32. The patch is not included in this mail because it is not very small (2383 lines, 73 Kb). It is however avalaible from:

http://arnaud.giersch.free.fr/parport_ip32/parport_ip32-latest.patch.gz

The patch is against the latest Linux/MIPS kernel (2.6.14-rc2 as of today). If you prefer that I post it on a mailing list, please just tell me where, and how (inlined, or gzip'ed attached file).

Further informations are available on:

http://arnaud.giersch.free.fr/parport_ip32.html

It superceeds git-rename by adding functionality to move multiple files, directories or symlinks into another directory. It also provides according documentation.

The implementation renames multiple files, using the arguments from the command line to produce an array of sources and destinations. In a first pass, all requested renames are checked for errors, and overwriting of existing files is only allowed with '-f'. The actual renaming is done in a second pass. This ensures that any error condition is checked before anything is changed.

The recent request on the list for "mv" in GIT reminded me about an addition to git-rename I made a week ago. I renamed it to "git-mv" and added some documentation.

If this works, we can remove git-rename sometimes in the future.

I should complement this command with tests. Also, a nice addition would be to support an interactive mode like 'mv', by asking if files should be overwritten.

By the way, it also checks for a request to move a directory into itself, which of course is an error.

Option "-k" is good for this: E.g. a "git-mv -k * dir" moves all revision controlled files and directories (but not "dir"!) into "dir". "-k" makes sure that the errors (trying to move "dir" into itself, or move files without revision control around) will not terminate the command but silently ignored and skipped. "-k" was taken from "make": Continue even on an error.

To generate the diff for a commit, gitk used to do

git-diff-tree -p -C $p $id

(and same thing to generate filenames, except using just "-r" there) which does actually generate the diff from the parent to the $id, exactly like it meant to do.

However, that really sucks with --dense, where the "parent" information has all been rewritten to point to the previous commit. The diff actually works exactly right, but now it's the diff of the _whole_ sequence of commits all the way to the previous commit that last changed the file(s) that we are looking at.

And that's really not what we want 99.9% of the time, even if it may be perfectly sensible. Not only will the diff not actually match the commit message, but it will usually be _huge_, and all of it will be totally uninteresting to us, since we were only interested in a particular set of files.

It also doesn't match what we do when we write the patch to a file.

So this makes gitk just show the diff of _that_ commit.

We might even want to have some way to limit the diff to only the filenames we're interested in, but it's often nice to see what else changed at the same time, so that's secondary.

The merge diff handling is left alone, although I think that should also be changed to only look at what that _particular_ merge did, not what it did when compared to the faked-out parents.

Ok, it's finally there.

2.6.14 was delayed twice due to some last-minute bug-reports, some of which ended up being false alarms (hey, I should be happy, but it was a bit frustrating)

But hey, the delays - even when perhaps unnecessary - got us to look at the code and fix some other bugs instead. So it's all good.

So special thanks go to Oleg Nesterov and Roland McGrath for doing some code inspection and fixing and just making the otherwise frustrating wait for bug resolution more productive ;^p.

Let's try the 2-week merge window thing again, I think it worked pretty well despite the delays, and hopefully it will work even better this time around.

The actual changes from 2.6.14-rc5 are a number of mostly one-liners, with the ShortLog appended (full log from 2.6.13 on the normal sites together with the release itself). The only slightly bigger ones (ie more than a handful of lines) is a kernel parameter doc update, and the PIIX4 PCI quirk printouts, and the cleanups/fixes for the posix cpu timers.

(In fact, according to diffstat, about half the diff is that one documentation update, and most of that is whitespace cleanups)

one of the downsides of the new "merge lots of stuff early in the development series" approach is that the first few daily snapshots end up being _huge_.

So the -git1 and -git2 patches are/will be very big indeed.

For example, patch-2.6.14-git1 literally ended up being a megabyte compressed. Right now my diff to 2.6.14 (after just two days) is 1.6MB compressed.

Admittedly, some of it is due to things like the MIPS merge, but the point I'm trying to make is that it makes the daily snapshot diffs a lot less useful to people who try to figure out where something broke.

Now, I've gotten several positive comments on how easy "git bisect" is to use, and I've used it myself, but this is the first time that patch users _really_ become very much second-class citizens, and you can't necessarily always do useful things with just the tar-trees and patches. That's sad, and possibly a really big downside.

Don't get me wrong - I personally think that the new merge policy is a clear improvement, but it does have this downside.

Back when I did the BK snapshots, I would occasionally do a middle-of-the-day snapshot if there were a ton of incoming merges in a 24-hour span.

If this "huge -git1" becomes a real problem, we could always

• give you a manual "do snapshot" button
• ask the maintainers to spread out their submits across multiple days, as I am doing now
• sell you on capping the daily push-to-kernel.org limit. merge stuff into "day1", "day2", etc. branches when the main branch "fills up" for the day.

None of these are terribly painful, but none are terribly appealing either.

The following series of patches divides swsusp into two functionally independent subsystems:

• the snapshot-handling part responsible for creating and populating the snapshot-related data structure which is the list of page backup entries aka pagedir,
• the swap-handling part responsible for writing the snapshot data to and reading it from swap.

On suspend the snapshot-handling part creates the system snapshot and makes the data stored in the snapshot available to the swap-handling part via an interface function allowing it to transfer the data as a series of consecutive data pages, in a specific order. The swap-handling part writes the data pages to a swap partition is such a way that they can be read in exactly the same order in which they have been saved.

On resume the snapshot-handling part is invoked by the swap-handling part to create the pagedir. Then, the swap-handling part is allowed to send it, with the help of an interface function, data pages that are used to populate the snapshot data structure. It is assumed that the data pages will be sent in the same order in which they have been received by the swap-handling part on suspend. Finally, the system state (from before suspend) is restored by the snaphot-handling part from the data structure handled by it.

From the point of view of the swap-handling part, the contents of the data pages provided by the snapshot-handling do not matter at all. It handles each data page in the same way without analyzing its contents and the snapshot-handling part is responsible for recognizing the metadata and using them as appropriate. Consequently, in principle the swap-handling part can be replaced with a user-space process and the interface functions used in transferring data between the two parts of swsusp can be replaced with a relatively simple kernel-user interface in the future.

The approach used in this series of patches has some additional benefits:

1. the size of the pagedir is reduced by 1/4 which causes some more memory to be available on resume,
2. the amount of metadata written to swap is reduced by 3/4,
3. the artificial limitation on the pagedir size, imposed by the size of the swsusp_info structure, is lifted,
4. the size of swsusp_info structure is reduced so it can be merged with the swsusp_header structure in the future,
5. the swap-handling part does not use any global variables related to the snapshot data structure,
6. the __nosavedata variables are almost eliminated (on x86-64 the last of them is the in_suspend variable).

I have divided the changes into some more or less logical steps for clarity. Although the code has been designed as proof-of-concept, it is functional and has been tested on x86-64, except for the cryptographic functionality and error paths.

For your convenience the patches are available from: http://www.sisk.pl/kernel/patches/2.6.14-rc5-mm1/

As I said in the 0.99.8 announcement, git already does everything I want it to do, and from here on I'd like to see us concentrate on fixes (both correctness and performance) until we hit 1.0 which should happen shortly.

Many thanks to everybody who contributed the comments, extra set of eyeballs, and code.

one thing I'd like to see (maybe it already exists and I just have overlooked it) is some kind of simple readme or something about the different ways to limit the output of the various git commands.

I've several times been surprised to see people not realize that "git-whatchanged" takes a file list to limit the files it is interested in. I also suspect people don't realize that you can limit it by time and version and file list, all at the same time.

IOW,

git-whatchanged -p --pretty=short --since="2 weeks ago" v0.99.8..v0.99.9 Makefile

is a valid query: it basically asks for any change to the Makefile in between versions v0.99.8..v0.99.9, _and_ within the last two weeks, and asks to show it as a patch, with the shortened commit message.

Is it useful? The above exact line almost certainly isn't, but variations on the above definitely are. And I suspect a lot of people never even realized you could do something like that.

(The danger with date-based things is that something may be 4 months old, but it only got _merged_ yesterday, so it may be new to _you_. And the --since="2 weeks ago" will not show it, which can be surprising to people who expect things that are new to _them_ to be shown).

The above limiters now work with "git log" and "gitk" too (they've worked for a long time with "git-whatchanged", but only with the new git-rev-list functionality does the name-limiting work for the other commands).

It would be good to make this more well-known, because a lot of people probably end up using git not as developers, but just to follow what is going on. And then the different limiters are some of the most important parts (the date-one is likely the least important one, but limiting by version and name is _very_ important).

I've somewhat updated git-rev-list documentation and tried to categorize the options into commit selectors and presentation modifiers. The documentation for commands you mentioned in your message all talk about them describing only frequently used options, and refer the user to rev-list documentation. I am not sure this would be enough.

One good thing to have would be to add a section to Tutorial. Currently we cover building a small project from scratch and have the readers graduate when they learn basic commit swapping, but we do not talk much about archaeology tools.

I don't think people really follow the links or think very abstractly at all in the first place.

So I was thinking more of some explicit examples. I actually think every command should have an example in the man-page, and hey, here's a patch to start things off.

Of course, I'm not exactly "Mr Documentation", and I don't know that this is the prettiest way to do this, but I checked that the resulting html and man-page seems at least reasonable.

And hey, if the examples look like each other, that's just because I'm also not "Mr Imagination".

Apparently the osdl mail server (and bugzilla etc) had a disk failure overnight.

My (and yours, Andrew) mail should be starting to trickle in now. Just a little bit delayed ;)

If you go to a kernel.org mirror and look at:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/

And then at the kernel you are interested in, e.g. lets take the latest -mm, then you will find the full -mm patch and the broken out bits in the following URLs respectively:

full mm:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/ 2.6.14-rc5-mm1/

broken out:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/ 2.6.14-rc5-mm1/broken-out/

And thusly, the ntfs patch from the developmental ntfs git repository would be:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/ 2.6.14-rc5-mm1/broken-out/git-ntfs.patch

It is also worth looking in the broken out directory for other patches with ntfs in the name, as Andrew may have other ntfs patches. In the above -mm, there is for example:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/ 2.6.14-rc5-mm1/broken-out/ntfs-printk-warning-fixes.patch

Here are the same "delete devfs" patches that I submitted for 2.6.12 and 2.6.13. It rips out all of devfs from the kernel and ends up saving a lot of space. Since 2.6.13 came out, I have seen no complaints about the fact that devfs was not able to be enabled anymore, and in fact, a lot of different subsystems have already been deleting devfs support for a while now, with apparently no complaints (due to the lack of users.)

Please pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
or if master.kernel.org hasn't synced up yet:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/

I've posted all of these patches before, but if people really want to look at them, they can be found at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/

Also, if people _really_ are in love with the idea of an in-kernel devfs, I have posted a patch that does this in about 300 lines of code, called ndevfs. It is available in the archives if anyone wants to use that instead (it is quite easy to maintain that patch outside of the kernel tree, due to it only needing 3 hooks into the main kernel tree.)

Version 0.3 of (H)gct, a GUI enabled commit tool for Git and Mercurial, has been released and can be downloaded from http://www.cyd.liu.se/~freku045/gct/ct-0.3.tar.gz

Thanks to Vincent Danjean there are Debian packages available at http://dept-info.labri.fr/~danjean/deb.html#commit-tool

Screen shots and a Git repository with a gitweb interface are available at the project homepage, http://www.cyd.liu.se/~freku045/gct

The major changes compared to v0.2 are:

• File filter, show only file names which contain a specified string.
• Make ignoring files actually work.
• A new option, --one-shot, which makes (h)gct exit after the first commit.
• Support for new versions of git.
• An Hg extension which makes hgct better integrated with Hg. See README.HG for details.