History log of /linux/scripts/patch-kernel (Results 126 – 129 of 129)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v2.6.12-rc5
# 67394f8f 21-May-2005 Anton Altaparmakov <aia21@cantab.net>

Merge with /usr/src/ntfs-2.6.git


# ad34ea2c 20-May-2005 James Bottomley <jejb@titanic.(none)>

merge by hand - fix up rejections in Documentation/DocBook/Makefile


Revision tags: v2.6.12-rc4
# 1922163c 06-May-2005 Randy.Dunlap <rddunlap@osdl.org>

[PATCH] patch-kernel: support non-incremental 2.6.x.y 'stable' patches

Add better support for (non-incremental) 2.6.x.y patches; If an ending
version number if not specified, the script automaticall

[PATCH] patch-kernel: support non-incremental 2.6.x.y 'stable' patches

Add better support for (non-incremental) 2.6.x.y patches; If an ending
version number if not specified, the script automatically increments the
SUBLEVEL (x in 2.6.x.y) until no more patch files are found; however,
EXTRAVERSION (y in 2.6.x.y) is never automatically incremented but must be
specified fully.

patch-kernel does not normally support reverse patching, but does so when
applying EXTRAVERSION (x.y) patches, so that moving from 2.6.11.y to
2.6.11.z is easy and handled by the script (reverse 2.6.11.y and apply
2.6.11.z).

Signed-off-by: Randy Dunlap <rddunlap@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

show more ...


Revision tags: v2.6.12-rc3, v2.6.12-rc2
# 1da177e4 17-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org>

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

show more ...


123456