[libata ahci] minor remove/unplug path cleanup
tree 823f9aec427a108c873e50f215e36d225661a068
parent 1fdab81e675c6ef76a49b8aabb7eaf4be51d1b80
author Jeff Garzik [EMAIL PROTECTED] Tue, 30 Aug 2005 12:18:28 -0400
committer Jeff Garzik [EMAIL PROTECTED] Tue, 30 Aug 2005 12:18:28 -0400
[libata ahci] minor remove/unplug path cleanup
Don't bother calling a hook, to call our own module, to call a helper
than simply calls ionumap().
If you unroll all that convolution, you get a simple kfree()+iounmap()
pair of calls.
drivers/scsi/ahci.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
--- a/drivers/scsi/ahci.c
+++ b/drivers/scsi/ahci.c
@@ -189,7 +189,6 @@ static void ahci_irq_clear(struct ata_po
static void ahci_eng_timeout(struct ata_port *ap);
static int ahci_port_start(struct ata_port *ap);
static void ahci_port_stop(struct ata_port *ap);
-static void ahci_host_stop(struct ata_host_set *host_set);
static void ahci_tf_read(struct ata_port *ap, struct ata_taskfile *tf);
static void ahci_qc_prep(struct ata_queued_cmd *qc);
static u8 ahci_check_status(struct ata_port *ap);
@@ -242,7 +241,6 @@ static struct ata_port_operations ahci_o
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
- .host_stop = ahci_host_stop,
};
static struct ata_port_info ahci_port_info[] = {
@@ -301,14 +299,6 @@ static inline void *ahci_port_base (void
return (void *) ahci_port_base_ul((unsigned long)base, port);
}
-static void ahci_host_stop(struct ata_host_set *host_set)
-{
- struct ahci_host_priv *hpriv = host_set-private_data;
- kfree(hpriv);
-
- ata_host_stop(host_set);
-}
-
static int ahci_port_start(struct ata_port *ap)
{
struct device *dev = ap-host_set-dev;
@@ -1089,7 +1079,8 @@ static void ahci_remove_one (struct pci_
scsi_host_put(ap-host);
}
- host_set-ops-host_stop(host_set);
+ kfree(hpriv);
+ iounmap(host_set-mmio_base);
kfree(host_set);
if (have_msi)
@@ -1106,7 +1097,6 @@ static int __init ahci_init(void)
return pci_module_init(ahci_pci_driver);
}
-
static void __exit ahci_exit(void)
{
pci_unregister_driver(ahci_pci_driver);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[libata] __iomem annotations for various drivers
tree aa83ab9aa74e85b7a5c76f40764514a6ac266226
parent e005f01de32f22be8af255f2761018e9766000d2
author Jeff Garzik [EMAIL PROTECTED] Tue, 30 Aug 2005 13:18:18 -0400
committer Jeff Garzik [EMAIL PROTECTED] Tue, 30 Aug 2005 13:18:18 -0400
[libata] __iomem annotations for various drivers
drivers/scsi/ahci.c | 33 +
drivers/scsi/ata_piix.c |2 +-
drivers/scsi/sata_promise.c | 12 ++--
drivers/scsi/sata_sil.c |5 +++--
drivers/scsi/sata_svw.c |2 +-
drivers/scsi/sata_sx4.c | 39 ---
6 files changed, 48 insertions(+), 45 deletions(-)
diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
--- a/drivers/scsi/ahci.c
+++ b/drivers/scsi/ahci.c
@@ -294,9 +294,9 @@ static inline unsigned long ahci_port_ba
return base + 0x100 + (port * 0x80);
}
-static inline void *ahci_port_base (void *base, unsigned int port)
+static inline void __iomem *ahci_port_base (void __iomem *base, unsigned int
port)
{
- return (void *) ahci_port_base_ul((unsigned long)base, port);
+ return (void __iomem *) ahci_port_base_ul((unsigned long)base, port);
}
static int ahci_port_start(struct ata_port *ap)
@@ -304,8 +304,9 @@ static int ahci_port_start(struct ata_po
struct device *dev = ap-host_set-dev;
struct ahci_host_priv *hpriv = ap-host_set-private_data;
struct ahci_port_priv *pp;
- void *mem, *mmio = ap-host_set-mmio_base;
- void *port_mmio = ahci_port_base(mmio, ap-port_no);
+ void __iomem *mmio = ap-host_set-mmio_base;
+ void __iomem *port_mmio = ahci_port_base(mmio, ap-port_no);
+ void *mem;
dma_addr_t mem_dma;
pp = kmalloc(sizeof(*pp), GFP_KERNEL);
@@ -373,8 +374,8 @@ static void ahci_port_stop(struct ata_po
{
struct device *dev = ap-host_set-dev;
struct ahci_port_priv *pp = ap-private_data;
- void *mmio = ap-host_set-mmio_base;
- void *port_mmio = ahci_port_base(mmio, ap-port_no);
+ void __iomem *mmio = ap-host_set-mmio_base;
+ void __iomem *port_mmio = ahci_port_base(mmio, ap-port_no);
u32 tmp;
tmp = readl(port_mmio + PORT_CMD);
@@ -536,8 +537,8 @@ static void ahci_qc_prep(struct ata_queu
static void ahci_intr_error(struct ata_port *ap, u32 irq_stat)
{
- void *mmio = ap-host_set-mmio_base;
- void *port_mmio = ahci_port_base(mmio, ap-port_no);
+ void __iomem *mmio = ap-host_set-mmio_base;
+ void __iomem *port_mmio = ahci_port_base(mmio, ap-port_no);
u32 tmp;
int work;
@@ -585,8 +586,8 @@ static void ahci_intr_error(struct ata_p
static void ahci_eng_timeout(struct ata_port *ap)
{
struct ata_host_set *host_set = ap-host_set;
- void *mmio = host_set-mmio_base;
- void *port_mmio = ahci_port_base(mmio, ap-port_no);
+ void __iomem *mmio = host_set-mmio_base;
+ void __iomem *port_mmio = ahci_port_base(mmio, ap-port_no);
struct ata_queued_cmd *qc;
unsigned long flags;
@@ -616,8 +617,8 @@ static void ahci_eng_timeout(struct ata_
static inline int ahci_host_intr(struct ata_port *ap, struct ata_queued_cmd
*qc)
{
- void *mmio = ap-host_set-mmio_base;
- void *port_mmio = ahci_port_base(mmio, ap-port_no);
+ void __iomem *mmio = ap-host_set-mmio_base;
+ void __iomem *port_mmio = ahci_port_base(mmio, ap-port_no);
u32 status, serr, ci;
serr = readl(port_mmio + PORT_SCR_ERR);
@@ -653,7 +654,7 @@ static irqreturn_t ahci_interrupt (int i
struct ata_host_set *host_set = dev_instance;
struct ahci_host_priv *hpriv;
unsigned int i, handled = 0;
- void *mmio;
+ void __iomem *mmio;
u32 irq_stat, irq_ack = 0;
VPRINTK(ENTER\n);
@@ -699,7 +700,7 @@ static irqreturn_t ahci_interrupt (int i
static int ahci_qc_issue(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc-ap;
- void *port_mmio = (void *) ap-ioaddr.cmd_addr;
+ void __iomem *port_mmio = (void __iomem *) ap-ioaddr.cmd_addr;
writel(1, port_mmio + PORT_CMD_ISSUE);
readl(port_mmio + PORT_CMD_ISSUE); /* flush */
@@ -884,7 +885,7 @@ static void ahci_print_info(struct ata_p
{
struct ahci_host_priv *hpriv = probe_ent-private_data;
struct pci_dev *pdev = to_pci_dev(probe_ent-dev);
- void *mmio = probe_ent-mmio_base;
+ void __iomem *mmio = probe_ent-mmio_base;
u32 vers, cap, impl, speed;
const char *speed_s;
u16 cc;
@@ -957,7 +958,7 @@ static int ahci_init_one (struct pci_dev
struct ata_probe_ent *probe_ent = NULL;
struct ahci_host_priv *hpriv;
unsigned long base;
- void *mmio_base;
+ void __iomem *mmio_base;
unsigned int board_idx = (unsigned int) ent-driver_data;
int have_msi, pci_dev_busy = 0;
int rc;
diff --git a/drivers/scsi/ata_piix.c b/drivers/scsi/ata_piix.c
---
[libata] allow ATAPI to be enabled with new atapi_enabled module option
tree 486aa6a40ea419c14d02bc8561cdb8485f6a5189
parent 1fdab81e675c6ef76a49b8aabb7eaf4be51d1b80
author Jeff Garzik [EMAIL PROTECTED] Tue, 30 Aug 2005 11:37:42 -0400
committer Jeff Garzik [EMAIL PROTECTED] Tue, 30 Aug 2005 11:37:42 -0400
[libata] allow ATAPI to be enabled with new atapi_enabled module option
ATAPI is getting close to being ready. To increase exposure, we enable
the code in the upstream kernel, but default it to off (present
behavior). Users must pass atapi_enabled=1 as a module option (if
module) or on the kernel command line (if built in) to turn on
discovery of their ATAPI devices.
drivers/scsi/libata-core.c |4
drivers/scsi/libata-scsi.c |8
drivers/scsi/libata.h |1 +
include/linux/libata.h |1 -
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -75,6 +75,10 @@ static void __ata_qc_complete(struct ata
static unsigned int ata_unique_id = 1;
static struct workqueue_struct *ata_wq;
+int atapi_enabled = 0;
+module_param(atapi_enabled, int, 0444);
+MODULE_PARM_DESC(atapi_enabled, Enable discovery of ATAPI devices (0=off,
1=on));
+
MODULE_AUTHOR(Jeff Garzik);
MODULE_DESCRIPTION(Library module for ATA devices);
MODULE_LICENSE(GPL);
diff --git a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c
--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -1470,10 +1470,10 @@ ata_scsi_find_dev(struct ata_port *ap, s
if (unlikely(!ata_dev_present(dev)))
return NULL;
-#ifndef ATA_ENABLE_ATAPI
- if (unlikely(dev-class == ATA_DEV_ATAPI))
- return NULL;
-#endif
+ if (atapi_enabled) {
+ if (unlikely(dev-class == ATA_DEV_ATAPI))
+ return NULL;
+ }
return dev;
}
diff --git a/drivers/scsi/libata.h b/drivers/scsi/libata.h
--- a/drivers/scsi/libata.h
+++ b/drivers/scsi/libata.h
@@ -38,6 +38,7 @@ struct ata_scsi_args {
};
/* libata-core.c */
+extern int atapi_enabled;
extern struct ata_queued_cmd *ata_qc_new_init(struct ata_port *ap,
struct ata_device *dev);
extern void ata_qc_free(struct ata_queued_cmd *qc);
diff --git a/include/linux/libata.h b/include/linux/libata.h
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -40,7 +40,6 @@
#undef ATA_VERBOSE_DEBUG /* yet more debugging output */
#undef ATA_IRQ_TRAP/* define to ack screaming irqs */
#undef ATA_NDEBUG /* define to disable quick runtime checks */
-#undef ATA_ENABLE_ATAPI/* define to enable ATAPI support */
#undef ATA_ENABLE_PATA /* define to enable PATA support in some
* low-level drivers */
#undef ATAPI_ENABLE_DMADIR /* enables ATAPI DMADIR bridge support */
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[libata] fix ATAPI-enable typo
tree 157728e07af3efc756737108b01f9feee40eb360
parent 1623c81eece58740279b8de802fa5895221f2044
author Jeff Garzik [EMAIL PROTECTED] Wed, 31 Aug 2005 05:52:18 -0400
committer Jeff Garzik [EMAIL PROTECTED] Wed, 31 Aug 2005 05:52:18 -0400
[libata] fix ATAPI-enable typo
Dumb typo spotted by Mark Lord.
drivers/scsi/libata-scsi.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c
--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -1470,7 +1470,7 @@ ata_scsi_find_dev(struct ata_port *ap, s
if (unlikely(!ata_dev_present(dev)))
return NULL;
- if (atapi_enabled) {
+ if (!atapi_enabled) {
if (unlikely(dev-class == ATA_DEV_ATAPI))
return NULL;
}
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[WATCHDOG] Makefile-probe_order-patch
tree 0c65ed434e64101630ac04944040cf9b17ae6ca2 parent f505380ba7b98ec97bf25300c2a58aeae903530b author Wim Van Sebroeck [EMAIL PROTECTED] Wed, 17 Aug 2005 01:49:24 +0200 committer Wim Van Sebroeck [EMAIL PROTECTED] Sat, 03 Sep 2005 13:15:32 +0200 [WATCHDOG] Makefile-probe_order-patch Re-arrange Makefile according to what we want to probe first. Signed-off-by: Wim Van Sebroeck [EMAIL PROTECTED] drivers/char/watchdog/Makefile | 69 +++-- 1 files changed, 46 insertions(+), 23 deletions(-) diff --git a/drivers/char/watchdog/Makefile b/drivers/char/watchdog/Makefile --- a/drivers/char/watchdog/Makefile +++ b/drivers/char/watchdog/Makefile @@ -2,42 +2,65 @@ # Makefile for the WatchDog device drivers. # +# Only one watchdog can succeed. We probe the ISA/PCI/USB based +# watchdog-cards first, then the architecture specific watchdog +# drivers and then the architecture independant softdog driver. +# This means that if your ISA/PCI/USB card isn't detected that +# you can fall back to an architecture specific driver and if +# that also fails then you can fall back to the software watchdog +# to give you some cover. + +# ISA-based Watchdog Cards obj-$(CONFIG_PCWATCHDOG) += pcwd.o -obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o -obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o -obj-$(CONFIG_IB700_WDT) += ib700wdt.o obj-$(CONFIG_MIXCOMWD) += mixcomwd.o -obj-$(CONFIG_SCx200_WDT) += scx200_wdt.o -obj-$(CONFIG_60XX_WDT) += sbc60xxwdt.o obj-$(CONFIG_WDT) += wdt.o + +# PCI-based Watchdog Cards +obj-$(CONFIG_PCIPCWATCHDOG) += pcwd_pci.o obj-$(CONFIG_WDTPCI) += wdt_pci.o + +# USB-based Watchdog Cards +obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o + +# ARM Architecture obj-$(CONFIG_21285_WATCHDOG) += wdt285.o obj-$(CONFIG_977_WATCHDOG) += wdt977.o -obj-$(CONFIG_I8XX_TCO) += i8xx_tco.o -obj-$(CONFIG_MACHZ_WDT) += machzwd.o -obj-$(CONFIG_SH_WDT) += shwdt.o +obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o +obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o -obj-$(CONFIG_EUROTECH_WDT) += eurotechwdt.o -obj-$(CONFIG_W83877F_WDT) += w83877f_wdt.o -obj-$(CONFIG_W83627HF_WDT) += w83627hf_wdt.o -obj-$(CONFIG_SC520_WDT) += sc520_wdt.o -obj-$(CONFIG_ALIM7101_WDT) += alim7101_wdt.o + +# X86 (i386 + ia64 + x86_64) Architecture +obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o +obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o obj-$(CONFIG_ALIM1535_WDT) += alim1535_wdt.o -obj-$(CONFIG_SC1200_WDT) += sc1200wdt.o +obj-$(CONFIG_ALIM7101_WDT) += alim7101_wdt.o +obj-$(CONFIG_SC520_WDT) += sc520_wdt.o +obj-$(CONFIG_EUROTECH_WDT) += eurotechwdt.o +obj-$(CONFIG_IB700_WDT) += ib700wdt.o obj-$(CONFIG_WAFER_WDT) += wafer5823wdt.o +obj-$(CONFIG_I8XX_TCO) += i8xx_tco.o +obj-$(CONFIG_SC1200_WDT) += sc1200wdt.o +obj-$(CONFIG_SCx200_WDT) += scx200_wdt.o +obj-$(CONFIG_60XX_WDT) += sbc60xxwdt.o obj-$(CONFIG_CPU5_WDT) += cpu5wdt.o -obj-$(CONFIG_INDYDOG) += indydog.o -obj-$(CONFIG_PCIPCWATCHDOG) += pcwd_pci.o -obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o -obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o -obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o +obj-$(CONFIG_W83627HF_WDT) += w83627hf_wdt.o +obj-$(CONFIG_W83877F_WDT) += w83877f_wdt.o +obj-$(CONFIG_MACHZ_WDT) += machzwd.o + +# PowerPC Architecture obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o -# Only one watchdog can succeed. We probe the hardware watchdog -# drivers first, then the softdog driver. This means if your hardware -# watchdog dies or is 'borrowed' for some reason the software watchdog -# still gives you some cover. +# MIPS Architecture +obj-$(CONFIG_INDYDOG) += indydog.o + +# S390 Architecture + +# SUPERH Architecture +obj-$(CONFIG_SH_WDT) += shwdt.o + +# SPARC64 Architecture +# Architecture Independant obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[WATCHDOG] Kconfig+Makefile-clean
tree 6e58e256da91f7c78221b4f887c0d0479ca3f304 parent be3df0f94d77ba3cff40c14c3e21a753c40ba6f2 author Wim Van Sebroeck [EMAIL PROTECTED] Sat, 03 Sep 2005 13:46:56 +0200 committer Wim Van Sebroeck [EMAIL PROTECTED] Sat, 03 Sep 2005 13:46:56 +0200 [WATCHDOG] Kconfig+Makefile-clean Clean the Kconfig+Makefile according to a sorted list of the drivers of each architecture (and sub-architecture). Signed-off-by: Wim Van Sebroeck [EMAIL PROTECTED] drivers/char/watchdog/Kconfig | 43 - drivers/char/watchdog/Makefile |4 ++- 2 files changed, 25 insertions(+), 22 deletions(-) diff --git a/drivers/char/watchdog/Kconfig b/drivers/char/watchdog/Kconfig --- a/drivers/char/watchdog/Kconfig +++ b/drivers/char/watchdog/Kconfig @@ -84,6 +84,17 @@ config 977_WATCHDOG Not sure? It's safe to say N. +config IXP2000_WATCHDOG + tristate IXP2000 Watchdog + depends on WATCHDOG ARCH_IXP2000 + help + Say Y here if to include support for the watchdog timer + in the Intel IXP2000(2400, 2800, 2850) network processors. + This driver can be built as a module by choosing M. The module + will be called ixp2000_wdt. + + Say N if you are unsure. + config IXP4XX_WATCHDOG tristate IXP4xx Watchdog depends on WATCHDOG ARCH_IXP4XX @@ -100,17 +111,6 @@ config IXP4XX_WATCHDOG Say N if you are unsure. -config IXP2000_WATCHDOG - tristate IXP2000 Watchdog - depends on WATCHDOG ARCH_IXP2000 - help - Say Y here if to include support for the watchdog timer - in the Intel IXP2000(2400, 2800, 2850) network processors. - This driver can be built as a module by choosing M. The module - will be called ixp2000_wdt. - - Say N if you are unsure. - config S3C2410_WATCHDOG tristate S3C2410 Watchdog depends on WATCHDOG ARCH_S3C2410 @@ -346,6 +346,17 @@ config 8xx_WDT tristate MPC8xx Watchdog Timer depends on WATCHDOG 8xx +# PPC64 Architecture + +config WATCHDOG_RTAS + tristate RTAS watchdog + depends on WATCHDOG PPC_RTAS + help + This driver adds watchdog support for the RTAS watchdog. + + To compile this driver as a module, choose M here. The module + will be called wdrtas. + # MIPS Architecture config INDYDOG @@ -414,16 +425,6 @@ config WATCHDOG_RIO machines. The watchdog timeout period is normally one minute but can be changed with a boot-time parameter. -# ppc64 RTAS watchdog -config WATCHDOG_RTAS - tristate RTAS watchdog - depends on WATCHDOG PPC_RTAS - help - This driver adds watchdog support for the RTAS watchdog. - - To compile this driver as a module, choose M here. The module - will be called wdrtas. - # # ISA-based Watchdog Cards # diff --git a/drivers/char/watchdog/Makefile b/drivers/char/watchdog/Makefile --- a/drivers/char/watchdog/Makefile +++ b/drivers/char/watchdog/Makefile @@ -25,8 +25,8 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb. # ARM Architecture obj-$(CONFIG_21285_WATCHDOG) += wdt285.o obj-$(CONFIG_977_WATCHDOG) += wdt977.o -obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o +obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o @@ -50,6 +50,8 @@ obj-$(CONFIG_MACHZ_WDT) += machzwd.o # PowerPC Architecture obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o + +# PPC64 Architecture obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o # MIPS Architecture - To unsubscribe from this list: send the line unsubscribe git-commits-head in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[WATCHDOG] correct sysfs name for watchdog devices
tree 82dd082d2f40b0e86fac99893ff1ce44c73b635a
parent 09c8a9a0c0fe5b3182b6ecfa556fa77a55892c93
author Olaf Hering [EMAIL PROTECTED] Wed, 17 Aug 2005 08:58:34 +0200
committer Wim Van Sebroeck [EMAIL PROTECTED] Sat, 03 Sep 2005 13:51:18 +0200
[WATCHDOG] correct sysfs name for watchdog devices
While looking for possible candidates for our udev.rules package,
I found a few odd -name properties. /dev/watchdog has minor 130
according to devices.txt. Since all watchdog drivers use the
misc_register() call, they will end up in /sys/class/misc/$foo.
udev may create the /dev/watchdog node if the driver is loaded.
I dont have such a device, so I cant test it.
The drivers below provide names with spaces and even with / in it.
Not a big deal, but apps may expect /dev/watchdog.
Signed-off-by: Olaf Hering [EMAIL PROTECTED]
Signed-off-by: Wim Van Sebroeck [EMAIL PROTECTED]
drivers/char/watchdog/ixp2000_wdt.c |2 +-
drivers/char/watchdog/ixp4xx_wdt.c |2 +-
drivers/char/watchdog/scx200_wdt.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/watchdog/ixp2000_wdt.c
b/drivers/char/watchdog/ixp2000_wdt.c
--- a/drivers/char/watchdog/ixp2000_wdt.c
+++ b/drivers/char/watchdog/ixp2000_wdt.c
@@ -182,7 +182,7 @@ static struct file_operations ixp2000_wd
static struct miscdevice ixp2000_wdt_miscdev =
{
.minor = WATCHDOG_MINOR,
- .name = IXP2000 Watchdog,
+ .name = watchdog,
.fops = ixp2000_wdt_fops,
};
diff --git a/drivers/char/watchdog/ixp4xx_wdt.c
b/drivers/char/watchdog/ixp4xx_wdt.c
--- a/drivers/char/watchdog/ixp4xx_wdt.c
+++ b/drivers/char/watchdog/ixp4xx_wdt.c
@@ -176,7 +176,7 @@ static struct file_operations ixp4xx_wdt
static struct miscdevice ixp4xx_wdt_miscdev =
{
.minor = WATCHDOG_MINOR,
- .name = IXP4xx Watchdog,
+ .name = watchdog,
.fops = ixp4xx_wdt_fops,
};
diff --git a/drivers/char/watchdog/scx200_wdt.c
b/drivers/char/watchdog/scx200_wdt.c
--- a/drivers/char/watchdog/scx200_wdt.c
+++ b/drivers/char/watchdog/scx200_wdt.c
@@ -206,7 +206,7 @@ static struct file_operations scx200_wdt
static struct miscdevice scx200_wdt_miscdev = {
.minor = WATCHDOG_MINOR,
- .name = NAME,
+ .name = watchdog,
.fops = scx200_wdt_fops,
};
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[WATCHDOG] s3c2410 watchdog power management
tree 72ce7609578358929453e65c0c67796d5bff2b07
parent 2dab3cabc4b3c1ef53965233dc8a05e0ddeeb38e
author Ben Dooks [EMAIL PROTECTED] Wed, 17 Aug 2005 09:03:23 +0200
committer Wim Van Sebroeck [EMAIL PROTECTED] Sat, 03 Sep 2005 13:54:16 +0200
[WATCHDOG] s3c2410 watchdog power management
Patch from Dimitry Andric [EMAIL PROTECTED], updated
by Ben Dooks [EMAIL PROTECTED]. Patch is against 2.6.11-mm2
Add power management support to the s3c2410 watchdog, so that
it is shut-down over suspend, and re-initialised on resume.
Also add Dimitry to the list of authors.
Signed-off-by: Dimitry Andric [EMAIL PROTECTED]
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Signed-off-by: Wim Van Sebroeck [EMAIL PROTECTED]
drivers/char/watchdog/s3c2410_wdt.c | 51 +---
1 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/drivers/char/watchdog/s3c2410_wdt.c
b/drivers/char/watchdog/s3c2410_wdt.c
--- a/drivers/char/watchdog/s3c2410_wdt.c
+++ b/drivers/char/watchdog/s3c2410_wdt.c
@@ -27,7 +27,9 @@
* Fixed tmr_count / wdt_count confusion
* Added configurable debug
*
- * 11-Jan-2004 BJD Fixed divide-by-2 in timeout code
+ * 11-Jan-2005 BJD Fixed divide-by-2 in timeout code
+ *
+ * 25-Jan-2005 DA Added suspend/resume support
*
* 10-Mar-2005 LCVRChanged S3C2410_VA to S3C24XX_VA
*/
@@ -479,15 +481,57 @@ static int s3c2410wdt_remove(struct devi
return 0;
}
+#ifdef CONFIG_PM
+
+static unsigned long wtcon_save;
+static unsigned long wtdat_save;
+
+static int s3c2410wdt_suspend(struct device *dev, u32 state, u32 level)
+{
+ if (level == SUSPEND_POWER_DOWN) {
+ /* Save watchdog state, and turn it off. */
+ wtcon_save = readl(wdt_base + S3C2410_WTCON);
+ wtdat_save = readl(wdt_base + S3C2410_WTDAT);
+
+ /* Note that WTCNT doesn't need to be saved. */
+ s3c2410wdt_stop();
+ }
+
+ return 0;
+}
+
+static int s3c2410wdt_resume(struct device *dev, u32 level)
+{
+ if (level == RESUME_POWER_ON) {
+ /* Restore watchdog state. */
+
+ writel(wtdat_save, wdt_base + S3C2410_WTDAT);
+ writel(wtdat_save, wdt_base + S3C2410_WTCNT); /* Reset count */
+ writel(wtcon_save, wdt_base + S3C2410_WTCON);
+
+ printk(KERN_INFO PFX watchdog %sabled\n,
+ (wtcon_save S3C2410_WTCON_ENABLE) ? en : dis);
+ }
+
+ return 0;
+}
+
+#else
+#define s3c2410wdt_suspend NULL
+#define s3c2410wdt_resume NULL
+#endif /* CONFIG_PM */
+
+
static struct device_driver s3c2410wdt_driver = {
.name = s3c2410-wdt,
.bus= platform_bus_type,
.probe = s3c2410wdt_probe,
.remove = s3c2410wdt_remove,
+ .suspend= s3c2410wdt_suspend,
+ .resume = s3c2410wdt_resume,
};
-
static char banner[] __initdata = KERN_INFO S3C2410 Watchdog Timer, (c) 2004
Simtec Electronics\n;
static int __init watchdog_init(void)
@@ -505,7 +549,8 @@ static void __exit watchdog_exit(void)
module_init(watchdog_init);
module_exit(watchdog_exit);
-MODULE_AUTHOR(Ben Dooks [EMAIL PROTECTED]);
+MODULE_AUTHOR(Ben Dooks [EMAIL PROTECTED],
+ Dimitry Andric [EMAIL PROTECTED]);
MODULE_DESCRIPTION(S3C2410 Watchdog Device Driver);
MODULE_LICENSE(GPL);
MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[WATCHDOG] softdog-timer-running-oops.patch
tree 6e5f8ee1053e7add2ec1890b594dc4086ae39f09
parent 93642ecd463df30d032da8ac37c2676cee4ad876
author Chuck Ebbert [EMAIL PROTECTED] Fri, 19 Aug 2005 14:14:07 +0200
committer Wim Van Sebroeck [EMAIL PROTECTED] Sat, 03 Sep 2005 13:59:46 +0200
[WATCHDOG] softdog-timer-running-oops.patch
The softdog watchdog timer has a bug that can create an oops:
1. Load the module without the nowayout option.
2. Open the driver and close it without writing 'V' before close.
3. Unload the module. The timer will continue to run...
4. Oops happens when timer fires.
Reported Sun, 10 Oct 2004, by Michael Schierl [EMAIL PROTECTED]
Fix is easy: always take a reference on the module on open.
Release it only when the device is closed and no timer is running.
Tested on 2.6.13-rc6 using the soft_noboot option. While the
timer is running and the device is closed, the module use count
stays at 1. After the timer fires, it drops to 0. Repeatedly
opening and closing the driver caused no problems. Please apply.
Signed-off-by: Chuck Ebbert [EMAIL PROTECTED]
Signed-off-by: Wim Van Sebroeck [EMAIL PROTECTED]
drivers/char/watchdog/softdog.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/char/watchdog/softdog.c b/drivers/char/watchdog/softdog.c
--- a/drivers/char/watchdog/softdog.c
+++ b/drivers/char/watchdog/softdog.c
@@ -77,7 +77,7 @@ static void watchdog_fire(unsigned long)
static struct timer_list watchdog_ticktock =
TIMER_INITIALIZER(watchdog_fire, 0, 0);
-static unsigned long timer_alive;
+static unsigned long driver_open, orphan_timer;
static char expect_close;
@@ -87,6 +87,9 @@ static char expect_close;
static void watchdog_fire(unsigned long data)
{
+ if (test_and_clear_bit(0, orphan_timer))
+ module_put(THIS_MODULE);
+
if (soft_noboot)
printk(KERN_CRIT PFX Triggered - Reboot ignored.\n);
else
@@ -128,9 +131,9 @@ static int softdog_set_heartbeat(int t)
static int softdog_open(struct inode *inode, struct file *file)
{
- if(test_and_set_bit(0, timer_alive))
+ if (test_and_set_bit(0, driver_open))
return -EBUSY;
- if (nowayout)
+ if (!test_and_clear_bit(0, orphan_timer))
__module_get(THIS_MODULE);
/*
* Activate timer
@@ -147,11 +150,13 @@ static int softdog_release(struct inode
*/
if (expect_close == 42) {
softdog_stop();
+ module_put(THIS_MODULE);
} else {
printk(KERN_CRIT PFX Unexpected close, not stopping
watchdog!\n);
+ set_bit(0, orphan_timer);
softdog_keepalive();
}
- clear_bit(0, timer_alive);
+ clear_bit(0, driver_open);
expect_close = 0;
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe git-commits-head in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] Add a function for getting a struct tree for an ent.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
---
tree.c | 21 +
tree.h |3 +++
2 files changed, 24 insertions(+), 0 deletions(-)
3bfcc20b6aeff3e1fbcce97a426383c9770a2105
diff --git a/tree.c b/tree.c
--- a/tree.c
+++ b/tree.c
@@ -1,5 +1,7 @@
#include tree.h
#include blob.h
+#include commit.h
+#include tag.h
#include cache.h
#include stdlib.h
@@ -212,3 +214,22 @@ int parse_tree(struct tree *item)
free(buffer);
return ret;
}
+
+struct tree *parse_tree_indirect(const unsigned char *sha1)
+{
+ struct object *obj = parse_object(sha1);
+ do {
+ if (!obj)
+ return NULL;
+ if (obj-type == tree_type)
+ return (struct tree *) obj;
+ else if (obj-type == commit_type)
+ obj = (((struct commit *) obj)-tree-object);
+ else if (obj-type == tag_type)
+ obj = ((struct tag *) obj)-tagged;
+ else
+ return NULL;
+ if (!obj-parsed)
+ parse_object(obj-sha1);
+ } while (1);
+}
diff --git a/tree.h b/tree.h
--- a/tree.h
+++ b/tree.h
@@ -32,4 +32,7 @@ int parse_tree_buffer(struct tree *item,
int parse_tree(struct tree *tree);
+/* Parses and returns the tree in the given ent, chasing tags and commits. */
+struct tree *parse_tree_indirect(const unsigned char *sha1);
+
#endif /* TREE_H */
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] Add function to append to an object_list.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
---
object.c | 11 +++
object.h |3 +++
2 files changed, 14 insertions(+), 0 deletions(-)
88cf2db55848e7a2cf655171c7e9fd74c70a0281
diff --git a/object.c b/object.c
--- a/object.c
+++ b/object.c
@@ -184,6 +184,17 @@ struct object_list *object_list_insert(s
return new_list;
}
+void object_list_append(struct object *item,
+ struct object_list **list_p)
+{
+ while (*list_p) {
+ list_p = ((*list_p)-next);
+ }
+ *list_p = xmalloc(sizeof(struct object_list));
+ (*list_p)-next = NULL;
+ (*list_p)-item = item;
+}
+
unsigned object_list_length(struct object_list *list)
{
unsigned ret = 0;
diff --git a/object.h b/object.h
--- a/object.h
+++ b/object.h
@@ -41,6 +41,9 @@ void mark_reachable(struct object *obj,
struct object_list *object_list_insert(struct object *item,
struct object_list **list_p);
+void object_list_append(struct object *item,
+ struct object_list **list_p);
+
unsigned object_list_length(struct object_list *list);
int object_list_contains(struct object_list *list, struct object *obj);
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] Rewrite read-tree
Adds support for multiple ancestors, removes --emu23, much simplification.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
---
read-tree.c | 811 +++--
t/t1005-read-tree-m-2way-emu23.sh | 422 ---
2 files changed, 425 insertions(+), 808 deletions(-)
delete mode 100755 t/t1005-read-tree-m-2way-emu23.sh
f196469bec156947038f1d3d00c899c9044334ca
diff --git a/read-tree.c b/read-tree.c
--- a/read-tree.c
+++ b/read-tree.c
@@ -5,73 +5,291 @@
*/
#include cache.h
-static int stage = 0;
+#include object.h
+#include tree.h
+
+static int merge = 0;
static int update = 0;
-static int unpack_tree(unsigned char *sha1)
-{
- void *buffer;
- unsigned long size;
- int ret;
+static int head_idx = -1;
+static int merge_size = 0;
- buffer = read_object_with_reference(sha1, tree, size, NULL);
- if (!buffer)
- return -1;
- ret = read_tree(buffer, size, stage, NULL);
- free(buffer);
+static struct object_list *trees = NULL;
+
+static struct cache_entry df_conflict_entry = {
+};
+
+static struct tree_entry_list df_conflict_list = {
+ .name = NULL,
+ .next = df_conflict_list
+};
+
+typedef int (*merge_fn_t)(struct cache_entry **src);
+
+static int entcmp(char *name1, int dir1, char *name2, int dir2)
+{
+ int len1 = strlen(name1);
+ int len2 = strlen(name2);
+ int len = len1 len2 ? len1 : len2;
+ int ret = memcmp(name1, name2, len);
+ unsigned char c1, c2;
+ if (ret)
+ return ret;
+ c1 = name1[len];
+ c2 = name2[len];
+ if (!c1 dir1)
+ c1 = '/';
+ if (!c2 dir2)
+ c2 = '/';
+ ret = (c1 c2) ? -1 : (c1 c2) ? 1 : 0;
+ if (c1 c2 !ret)
+ ret = len1 - len2;
return ret;
}
-static int path_matches(struct cache_entry *a, struct cache_entry *b)
+static int unpack_trees_rec(struct tree_entry_list **posns, int len,
+ const char *base, merge_fn_t fn, int *indpos)
{
- int len = ce_namelen(a);
- return ce_namelen(b) == len
- !memcmp(a-name, b-name, len);
+ int baselen = strlen(base);
+ int src_size = len + 1;
+ do {
+ int i;
+ char *first;
+ int firstdir = 0;
+ int pathlen;
+ unsigned ce_size;
+ struct tree_entry_list **subposns;
+ struct cache_entry **src;
+ int any_files = 0;
+ int any_dirs = 0;
+ char *cache_name;
+ int ce_stage;
+
+ /* Find the first name in the input. */
+
+ first = NULL;
+ cache_name = NULL;
+
+ /* Check the cache */
+ if (merge *indpos active_nr) {
+ /* This is a bit tricky: */
+ /* If the index has a subdirectory (with
+* contents) as the first name, it'll get a
+* filename like foo/bar. But that's after
+* foo, so the entry in trees will get
+* handled first, at which point we'll go into
+* foo, and deal with bar from the index,
+* because the base will be foo/. The only
+* way we can actually have foo/bar first of
+* all the things is if the trees don't
+* contain foo at all, in which case we'll
+* handle foo/bar without going into the
+* directory, but that's fine (and will return
+* an error anyway, with the added unknown
+* file case.
+*/
+
+ cache_name = active_cache[*indpos]-name;
+ if (strlen(cache_name) baselen
+ !memcmp(cache_name, base, baselen)) {
+ cache_name += baselen;
+ first = cache_name;
+ } else {
+ cache_name = NULL;
+ }
+ }
+
+ if (first)
+ printf(index %s\n, first);
+
+ for (i = 0; i len; i++) {
+ if (!posns[i] || posns[i] == df_conflict_list)
+ continue;
+ printf(%d %s\n, i + 1, posns[i]-name);
+ if (!first || entcmp(first, firstdir,
+posns[i]-name,
+posns[i]-directory) 0) {
+ first = posns[i]-name;
+ firstdir = posns[i]-directory;
+ }
+ }
+ /* No name means we're done */
+
[PATCH 4/4] Document the trivial merge rules for 3(+more ancestors)-way merges.
Signed-off-by: Daniel Barkalow --- Documentation/technical/trivial-merge.txt | 92 + 1 files changed, 92 insertions(+), 0 deletions(-) create mode 100644 Documentation/technical/trivial-merge.txt 7544be0a8eda7b796150729a7795c2639278da62 diff --git a/Documentation/technical/trivial-merge.txt b/Documentation/technical/trivial-merge.txt new file mode 100644 --- /dev/null +++ b/Documentation/technical/trivial-merge.txt @@ -0,0 +1,92 @@ +Trivial merge rules +=== + +This document describes the outcomes of the trivial merge logic in read-tree. + +One-way merge +- + +This replaces the index with a different tree, keeping the stat info +for entries that don't change, and allowing -u to make the minimum +required changes to the working tree to have it match. + + index treeresult + --- + * (empty) (empty) + (empty) treetree + index+ treetree + index+ index index+ + +Two-way merge +- + + + +Three-way merge +--- + +It is permitted for the index to lack an entry; this does not prevent +any case from applying. + +If the index exists, it is an error for it not to match either the +head or (if the merge is trivial) the result. + +If multiple cases apply, the one used is listed first. + +A result of no merge means that index is left in stage 0, ancest in +stage 1, head in stage 2, and remote in stage 3 (if any of these are +empty, no entry is left for that stage). Otherwise, the given entry is +left in stage 0, and there are no other entries. + +A result of no merge is an error if the index is not empty and not +up-to-date. + +*empty* means that the tree must not have a directory-file conflict + with the entry. + +For multiple ancestors or remotes, a '+' means that this case applies +even if only one ancestor or remote fits; normally, all of the +ancestors or remotes must be the same. + +case ancestheadremoteresult + +1 (empty)+ (empty) (empty) (empty) +2ALT (empty)+ *empty* remoteremote +2ALT (empty)+ *empty* remoteremote +2 (empty)^ (empty) remoteno merge +3ALT (empty)+ head*empty* head +3 (empty)^ head(empty) no merge +4 (empty)^ headremoteno merge +5ALT * headhead head +6 ancest^ (empty) (empty) no merge +8ALT ancest(empty) ancest(empty) +7 ancest+ (empty) remoteno merge +9 ancest+ head(empty) no merge +10ALT ancestancest (empty) (empty) +11ancest+ headremoteno merge +16anc1/anc2 anc1anc2 no merge +13ancest+ headancesthead +14ancest+ ancest remoteremote +14ALT ancest+ ancest remoteremote + +Only #2ALT and #3ALT use *empty*, because these are the only cases +where there can be conflicts that didn't exist before. Note that we +allow directory-file conflicts between things in different stages +after the trivial merge. + +A possible alternative for #6 is (empty), which would make it like +#1. This is not used, due to the likelihood that it arises due to +moving the file to multiple different locations or moving and deleting +it in different branches. + +Case #1 is included for completeness, and also in case we decide to +put on '+' markings; any path that is never mentioned at all isn't +handled. + +Note that #16 is when both #13 and #14 apply; in this case, we refuse +the trivial merge, because we can't tell from this data which is +right. This is a case of a reverted patch (in some direction, maybe +multiple times), and the right answer depends on looking at crossings +of history or common ancestors of the ancestors. + +The status as of Sep 5 is that multiple remotes are not supported \ No newline at end of file - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure the diff machinery outputs \ No newline ... in english
On Sun, Sep 04, 2005 at 11:48:08AM -0700, Junio C Hamano wrote: Fredrik Kuivinen [EMAIL PROTECTED] writes: In non-english locales diff(1) do sometimes output \ No newline at end of file in some other language. Set LC_ALL to C before execing diff to avoid this behaviour. Signed-off-by: Fredrik Kuivinen [EMAIL PROTECTED] I was thinking about this when I was examining your other patch. What else, other than the incomplete line marker (and timestamp output it uses by default, which we disable by passing explicit -L flags), are affected by locale in diff output? After a quick look through the diff source I didn't find anything else. It's quite possible that I haved missed something though. Most of the translated messages are related to error reporting, which I guess might be nice to have in the user specified language. Especially, if the diff output is more readable for human consumers (i.e. reviewers) without making it harder to use to machine consumers (i.e. patch or git-apply) when generated under a locale that is 'native' to the data, this patch robs from users the possibility of doing so. IOW, in a Swedes-only project that tracks a document in Swedish, it _might_ be friendlier and more useful to the users if allowed generating diffs under sv_SE locale, as long as such a diff does not make the processing by patch and git-apply more difficult (which your other patch already solved for git-apply). I agree that it's kind of evil to remove the option of generating the output in some other language. Another possibility is to set LC_MESSAGES to C instead. If we go this way the user can override it by setting LC_ALL. The difference is that in most configurations the user has to make an active choice to get the 'native' language output and english will be the default. - Fredrik - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Update git-send-email-script with --compose
Ryan, is it possible to fix the git-send-email script to just work reading in the emails that `git-format-patch-script -o patchdir origin` generates? I have a very ugly local patch to git-send-email-script that - reads from from git-var, can be overridden by passing an explicit --from - reads subject from the first line of STDIN or file. If the line doesn't start with [PATCH it provides the [PATCH] prefix. I found it really confusing that it wants to get 'from' in the first line... that's not what git-format-patch produces! - it never prompts for anything I then invoke it with git-send-email-script --to git@vger.kernel.org patches/0001-bad-uglypatch and it just works. I haven't sent them anywhere because I just wanted it to work locally for me, and it's just a bunch of hacks. And you are clearly using something other than git-format-patch to generate those patchfiles -- and my patches would break that. OTOH, it'd be great if it did support the git-format-patch output. Let me know if you want bits and pieces of my hack - though it's trivial. cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
bogus merges
A recent commit in linux-2.6 looks like this: commit b129a8ccd53f74c43e4c83c8e0031a4990040830 Merge: 6b39374a27eb4be7e9d82145ae270ba02ea90dc8 194d0710e1a7fe92dcf860ddd31fded8c3103b7a Author: Russell King [EMAIL PROTECTED] Date: Wed Aug 31 10:12:14 2005 +0100 [SERIAL] Clean up and fix tty transmission start/stoping The problem is that two parents of this merge are separate. One is an ancestor of the other. This means the merge is really pointless and probably accidental. Really 'git commit' should detect problems like this automatically and prevent them from getting in the tree. -Wayne - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
Junio C Hamano wrote: 1 / \ 0-2-3-5-7 \ / 4-6 It shouldn't matter to the merge at 7 if the 2-3 reorganization was done locally, by applying a patch, or by merging. There was another problem in my message that treated #3 specially. I did it that way primarily because I wanted to have an algorithm that needs to look only limited (namely, one) number of commits, more than what we currently look at. The problem is that the trail #0..#1..#3 (in the example in second message, whose rename probably happened between #0 and #1) may change the contents of the renamed file so drastically that diff between #2 and #3 may not look like rename anymore, while we could still detect it if we followed the whole trail and looked for renames between each commit on it. One question, of course, is if one should simply keep additional metadata around to handle this sort of situations. One could, for example, keep a UUID for each file, which would be carried over by the renaming commit. If one runs into a tree which doesn't have the UUIDs, they should be generated at that time (this could be a bit tricky to do without invalidating all signatures in the tree, since the obvious way -- adding it to the tree object -- would invalidate all the commit and tag objects.) In some ways this is similar to the Unix filesystem model of separating location (pathname) from identity (device:inode). It would also hade the somewhat interesting possibility that one could remove and recreate a file and have it exist as a different entity. That probably needs to be a user option. -hpa - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Update git-send-email-script with --compose
On Mon, Sep 05, 2005 at 11:16:57PM +1200, Martin Langhoff wrote: Ryan, is it possible to fix the git-send-email script to just work reading in the emails that `git-format-patch-script -o patchdir origin` generates? I have a very ugly local patch to git-send-email-script that - reads from from git-var, can be overridden by passing an explicit --from git-send-email-script already reads the From: from git-var - but I suppose I should only *prompt* for the from if something isn't satisfactory with the output of git-var. TODO #1 - reads subject from the first line of STDIN or file. If the line doesn't start with [PATCH it provides the [PATCH] prefix. I found it really confusing that it wants to get 'from' in the first line... that's not what git-format-patch produces! Sorry about that - I always export using git-format-patch using --mbox, and those work nicely. I'm a bit reluctant to do the [PATCH] fixup, but I think I will: 1. Detect [PATCH] or [PATCH [0-9]+/[0-9]+] (Sorry for the horrid fake-regexp) 2. Provide a --no-fixup-subject to turn that off. (TODO #2) - it never prompts for anything I think I'm tending in that direction - I'll keep making the prompting a fall-back by adding better default detection. In this case, remember that this was an attempt to help users patch bomb lists, getting all the subtle details correct. The prompting is there to help get the subtle details correct! I then invoke it with git-send-email-script --to git@vger.kernel.org patches/0001-bad-uglypatch and it just works. I haven't sent them anywhere because I just wanted it to work locally for me, and it's just a bunch of hacks. And you are clearly using something other than git-format-patch to generate those patchfiles -- and my patches would break that. Well, I'm not. Try git format-patch --mbox -o patchdir origin and see if that works better for you. OTOH, it'd be great if it did support the git-format-patch output. Let me know if you want bits and pieces of my hack - though it's trivial. Sure, send it at me, and I'll see what I can incorporate. I do apologize for not realizing that the default git format-patch output doesn't match what git send-email script expects the legacy mode - I'll sort that out one way or another as well. (TODO #3) -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
On Mon, 5 Sep 2005, H. Peter Anvin wrote: It would also hade the somewhat interesting possibility that one could remove and recreate a file and have it exist as a different entity. That probably needs to be a user option. It's a totally broken model. Really. You think it solves issues, but it just creates more bugs and problems than it solves. Trust me. The whole point of git is that content is the only thing that matters, and that there isn't any other meta-data. If you break that fundamental assumption, everything git does so well will break. I think we've already shown that the content matters approach works. I claim that the git rename tracking works better than any other SCM out there, _exactly_ because it doesn't make the mistake of trying to track anything but content. The moved + modified files is not anything special. The current automatic merger may not handle it, but that's not because it _can't_ handle it, it's because it tries to be simple and efficient. And because it's so _incredibly_ fast for all the normal cases, you can now spend some effort on figuring out renames dynamically for the few cases where it fails. Does it do so now? No. Would adding UUID's help? Hell no. It would be just an unmitigated disaster. Exactly the same way git-diff-tree can figure out renames, a merge algorithm can figure them out. Right now, we have two stages in merges: we try the trivial merge first (pure git-read-tree), and when that fails, we try the automatic 3-way merge. The fact that we don't have a third (and fourth, and fifth) merge algorithm for when those two trivial merges happen to not work is _not_ an indication that the contents only approach doesn't work - it's just an indication of the fact that 99.9% of all merges are trivial, and they should be optimized for. So the next step is _not_ to do UUID's, it's to notice that merge errors happened, and try to figure out why. Right now we just give up and say sort it out by hand. That's actually a perfectly valid approach even in the presense of moved files - it's a bit painful, but once you _do_ sort it out and commit the merge, especially if you can push the merge back (so that both sides then agree on the final rename), future merges will be trivial again - ie you won't have to go through it over and over again. Of course, if you don't push it back, but keep the two trees separate and keep on modifying files that have different names in the other repository, you'll keep on getting into the situation that the trivial merge doesn't work. So we _do_ want to get an automated phase 3 (and maybe 4..) merge that can figure out renames, but the point here is that it's something we _can_ figure out. For example, one way of doing it is to just do the exact merge we do now, and then look at the files that didn't merge. Do a cross-diff between such files and new/deleted files (if not _exactly_ the way we do for git diff -M, then at least it's exactly the same concept), and try to do a three-way merge where the base/first/second pairs don't have the same name. For example, let's say that you have the common commit A, and file x, and two paths (B and C) where B has renamed the file x to y, and C has modified file x. You end up with the schenario that our trivial merge fails to handle, and right now we give up, and don't help the user very much at all. But the _solution_ is not to change read-tree to know about renames, nor is it to make git keep any new data. The solution is to just make phase 3 say: - Automatic merge failed, trying rename merge - go through all files that exist in C but not in B (or vice versa), and pair them up with all files that exist in B but not in C (or vice versa) and see if _they_ can be handled as a three-way merge. And exactly the same way that we do the rename detection, we may want to find the optimal pairing by looking at the distance between the files. Notice? This will automatically handle the renamed in one branch, modified in another case. In fact, if the renamer modified it too, that's not a problem at all - the three-way merge will work exactly the same way it does now with the case of a non-moved modified in both files. Problem solved. Without complicating the trivial (and very common) cases, and without introducing any new metadata that is fundamentally impossible to maintain (and it _is_ fundamentally impossible to maintain, because it has nothing to do with the contents of the files, so patches etc will by definition break it). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bogus merges
On Mon, 5 Sep 2005, Wayne Scott wrote: A recent commit in linux-2.6 looks like this: It hopefully shouldn't happen any more with the improved and fixed git-merge-base. Author: Russell King [EMAIL PROTECTED] Date: Wed Aug 31 10:12:14 2005 +0100 I suspect rmk is using cogito-0.13, and that it still has the older git-merge-base that can get confused by the date-ordering problem. And when git-merge-base gives the wrong result (not either of the commit objects it was given as an argument), then git resolve will do the wrong thing. I just checked, and the _current_ git-merge-base definitely gives the right result: linux$ git-merge-base -a \ 6b39374a27eb4be7e9d82145ae270ba02ea90dc8 \ 194d0710e1a7fe92dcf860ddd31fded8c3103b7a results in 194d0710e1a7fe92dcf860ddd31fded8c3103b7a ie it correctly notices that the second commit is the parent of the first one. Really 'git commit' should detect problems like this automatically and prevent them from getting in the tree. Well, that would depend on having the fixed git-merge-base in the first place, which in turn would mean that such a commit wouldn't happen at all, so it's kind of circular. It's not worth fixing anywhere else, since once you fix it in git-merge-base, it just becomes a non-issue. Hopefully we'll have a new cogito release soon, and this particular bug will be a thing of the past. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
On Mon, 5 Sep 2005, David Kågedal wrote: But to the users (like myself), there's no point in naming it by whether it's a script or a binary. So? There's no downside. To you, as a user, you never see the -script ending anyway. You'd never type it out, or you're already doing something wrong. So to users it doesn't matter, and to developers it _does_ matter (and calling them .pl or .sh or something would be _bad_), why not please the developers? So your argument that it makes it easier for git developers to work with the source doesn't help the user. It doesn't _help_ the user, but since it doesn't hurt him either, why the hell would we even _care_ about the user? Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 5 Sep 2005, David Kågedal wrote: But to the users (like myself), there's no point in naming it by whether it's a script or a binary. So? There's no downside. To you, as a user, you never see the -script ending anyway. You'd never type it out, or you're already doing something wrong. Then I'm doing something wrong. And I'm pretty sure others are too. If I'm not supposed to see the -script ending, then don't install it in my $PATH. Until someone (possibly myself) writes some zsh completion code to handle git sub command, I will continue to hit TAB and see all those names. Furthermore, the man page for git clone is called git-clone-script(1). And the -script suffix appears inside the documentation in various places. I see it in howtos and log messages. And the git-merge-one-file-script script is supposed to be used in a way where I have to supply the long name. Etc. If the -script part is supposed to be hidden from me, why do I keep seeing it everywhere I turn? So to users it doesn't matter, and to developers it _does_ matter (and calling them .pl or .sh or something would be _bad_), why not please the developers? I'm not suggesting we'd call them .pl or .sh. -- David Kågedal - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
Linus Torvalds wrote: It's a totally broken model. Really. You think it solves issues, but it just creates more bugs and problems than it solves. Trust me. The whole point of git is that content is the only thing that matters, and that there isn't any other meta-data. If you break that fundamental assumption, everything git does so well will break. I think we've already shown that the content matters approach works. I claim that the git rename tracking works better than any other SCM out there, _exactly_ because it doesn't make the mistake of trying to track anything but content. The moved + modified files is not anything special. The current automatic merger may not handle it, but that's not because it _can't_ handle it, it's because it tries to be simple and efficient. And because it's so _incredibly_ fast for all the normal cases, you can now spend some effort on figuring out renames dynamically for the few cases where it fails. Does it do so now? No. Would adding UUID's help? Hell no. It would be just an unmitigated disaster. Okay, how about keeping a cache (derived from the contents) of these types of data, to assist the merge if necessary? If it doesn't exist when needed, it can just be created, which may take O(n) time. -hpa - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Missing documentation
The following is the list of files in the Documentation directory that have *NO* useful text in them at all. git-build-rev-cache.txt git-checkout-script.txt git-diff-script.txt git-format-patch-script.txt git-get-tar-commit-id.txt git-reset-script.txt git-rev-parse.txt git-show-rev-cache.txt gitk.txt The list is the output of the following trivial script: cd Documentation grep -l 'Does something not yet documented.' * If you are the/an author of one or more of these commands (or anyone else), please create some documentation for it. If you care to, please review the rest of the documentation for out of date and/or incomplete text and either produce a patch or let Junio know so it can be added to the TODO list. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
Linus Torvalds [EMAIL PROTECTED] writes: Of course, if you don't push it back, but keep the two trees separate and keep on modifying files that have different names in the other repository, you'll keep on getting into the situation that the trivial merge doesn't work. So we _do_ want to get an automated phase 3 (and maybe 4..) merge that can figure out renames, but the point here is that it's something we _can_ figure out. Thanks. You very well said exactly what I should have said; I failed to explain where that `reusing rename information from previous merge` algorithm should fit in the bigger picture. And the algorithm you describe (and Daniel briefly outlined) is slightly different from what I had in mind in that it does not have to depend on previous merge, which is also nice. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Linus Torvalds [EMAIL PROTECTED] writes: ... and I don't see _any_ point to naming by what _kind_ of interpreter you use. Why would _anybody_ care whether something is written in perl vs shell? One possibility that comes to mind is to again help developers who use an editor that is syntax-aware and looks *only* at filename suffix to figure out which language syntax to use (Emacs is not one of them -- it knows how to read #! line). Another is, although we do not currently do it, to make the Makefile simpler if/when we start to do the interpreter line munging (#!/usr/bin/perl - #!/usr/local/bin/perl) before install time. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
H. Peter Anvin [EMAIL PROTECTED] writes: One question, of course, is if one should simply keep additional metadata around to handle this sort of situations. One could, for example, keep a UUID for each file,... If I am not mistaken, that is exactly what tla does. It seems to work well in practice and seem so simple (at least superficially, I have not looked deeply into the issues involved in keeping it sync with the contents and how to recover if the user ever screws up, etc.), and I can see why people find it so attractive. I myself once did. But previous argument by Linus made in a distant (in git timescale) past is now ingrained in my brain: the additional metadata recorded at the commit time can only help us what we envisioned in the past when the tool to record that metadata was written. If we try to track by contents, we can do at least the same (diff -M being able to tell renames is an example that we can get away without having a UUID) and possibly better, depending on how much effort we are willing to spend drilling down when we actually need to know what happened at merge time. What I found most important in that argument by Linus is that the drilling down algorithm can improve over time while the additional metadata specification is cast in stone when a commit is made. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git/cogito suggestion: tags with descriptions
Hi folks, I've been using git on my new projects, and loving it! When I use tags, I typically will use a name like 0.3_basic_description and 0.4_full_outline, because I want to know not only what version number I'm considering, but also the reason why I chose to tag that particular version. The problem is that when I want to seek to a particular version to see where my head was at, I have to do all that typing, or cut and paste the full text of the tag, which is not terribly annoying, but it seems unnecessary. The version number is the unique ID I'm really interested in, and the descriptive part of the name is just extra, so I know what I'm talking about. It would be great if tags also allowed a brief description to go along with them, that would show up in cg-tag-ls. Then I could seek to a tag that's just an easy-to-type version number, and still have an idea of what's significant about that version because of the descriptive text. Be well, Zack -- Zack Brown - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Update git-send-email-script with --compose
Ryan Anderson [EMAIL PROTECTED] writes: On Mon, Sep 05, 2005 at 11:16:57PM +1200, Martin Langhoff wrote: - reads subject from the first line of STDIN or file. If the line doesn't start with [PATCH it provides the [PATCH] prefix. I found it really confusing that it wants to get 'from' in the first line... that's not what git-format-patch produces! Sorry about that - I always export using git-format-patch using --mbox, and those work nicely. I'm a bit reluctant to do the [PATCH] fixup, but I think I will: 1. Detect [PATCH] or [PATCH [0-9]+/[0-9]+] (Sorry for the horrid fake-regexp) 2. Provide a --no-fixup-subject to turn that off. (TODO #2) To be consistent with the other tools in tools/ directory, the above is probably 's/^/[PATCH] / unless (/^\[PATCH/])' In this case, remember that this was an attempt to help users patch bomb lists, getting all the subtle details correct. The prompting is there to help get the subtle details correct! You could error out without asking if that is what is happening. Well, I'm not. Try git format-patch --mbox -o patchdir origin and see if that works better for you. Martin, --mbox has the added benefit that it consistently preserves the From: and Date: information even for your own patches, because it implies --date and --author. By default without --author and --date these are not preserved from the original commits for your own patches, primarily because format-patch without --mbox was written for reorganizing and reordering existing patches (i.e. export, concatenate some, edit some hunks, and eventually feed it to applymbox to make commits; you do not typically want to keep the original author date for this kind of use). I do apologize for not realizing that the default git format-patch output doesn't match what git send-email script expects the legacy mode - I'll sort that out one way or another as well. (TODO #3) I do apologize for not really saying what --mbox does and what the format-patch output without --mbox is meant for. Martin, is there a reason you do not want --mbox format (e.g. format-patch --mbox spits out Subject: line undesirably formatted while it does what you want without --mbox)? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git/cogito suggestion: tags with descriptions
Zack Brown [EMAIL PROTECTED] writes: It would be great if tags also allowed a brief description to go along with them, that would show up in cg-tag-ls. Then I could seek to a tag that's just an easy-to-type version number, and still have an idea of what's significant about that version because of the descriptive text. Would 'git tag -a' work for you? : siamese; git tag -a -m 'This is to just demonstrate.' test-for-brown : siamese; git cat-file tag test-for-brown object 0516de30e8bdd26086e2a3edd3375981fd0c34d6 type commit tag test-for-brown tagger Junio C Hamano [EMAIL PROTECTED] 1125946805 -0700 This is to just demonstrate. : siamese; BTW, when will the next issue of GIT traffic appear ;-)? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Update git-send-email-script with --compose
On 9/6/05, Junio C Hamano [EMAIL PROTECTED] wrote: Ryan Anderson [EMAIL PROTECTED] writes: Sorry about that - I always export using git-format-patch using --mbox, and those work nicely. I'm a bit reluctant to do the [PATCH] fixup, but I think I will: Thanks Ryan for the clarification! I hadn't realized it would work correctly with --mbox -- unfortunately it doesn't work very well in the one-file-per-patch (legacy?) mode. Also, telling it _not_ to prompt when it can guess it, is far better (a confirm y/n can still be a good thing if you want to ensure the user gets a chance to review the values guessed). Martin, --mbox has the added benefit that it consistently preserves the From: and Date: information even for your own patches, because it implies --date and --author. By default without --author and --date these are not preserved from the original commits for your own patches, primarily because format-patch without --mbox was written for reorganizing and reordering existing patches (i.e. export, concatenate some, edit some hunks, and eventually feed it to applymbox to make commits; you do not typically want to keep the original author date for this kind of use). Fair enough -- blame it on my primitive approach of only having 2 working repositories, and having some patches in them that I'm not pushing upstream. Exporting to mbox would mean that I have to edit the mbox file to remove the patches I don't intend to publish. ... and on my naive reading of git-send-email documentation -- it doesn't mention mbox format at all, so I assumed it would expect one patch per file. Martin, is there a reason you do not want --mbox format (e.g. format-patch --mbox spits out Subject: line undesirably formatted while it does what you want without --mbox)? Hmmm -- that I am too lazy to keep several heads or several repos, and organize them to have a tojunio branch? So far I've been working on one or two files (archimport) and customizing a couple of others with strictly local changes (git-send-email for instance), so it didn't make sense to formally segregate the heads. A simple review and manual cherrypicking of the patches I wanted to send was enough. cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Update git-send-email-script with --compose
Martin Langhoff [EMAIL PROTECTED] writes: Fair enough -- blame it on my primitive approach of only having 2 working repositories, and having some patches in them that I'm not pushing upstream. Exporting to mbox would mean that I have to edit the mbox file to remove the patches I don't intend to publish. ... and on my naive reading of git-send-email documentation -- it doesn't mention mbox format at all, so I assumed it would expect one patch per file. Not really; --mbox output is one-file-per-patch and it is up to you which ones to pick and concatenate them in what order, if you want them in a single file. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Update git-send-email-script with --compose
On 9/6/05, Junio C Hamano [EMAIL PROTECTED] wrote: Not really; --mbox output is one-file-per-patch and it is up to you which ones to pick and concatenate them in what order, if you want them in a single file. Hr. Then I better hide away in a little cave, and shut my big mouth up. ;-) It shows that I was never familiar with the practices of linux hackers. I've always read the references to mboxes holding patchbombs meaning literally one mbox file with a zillion contatenated patches received via email. apologies, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Update git-send-email-script with --compose
Martin Langhoff [EMAIL PROTECTED] writes: It shows that I was never familiar with the practices of linux hackers. I've always read the references to mboxes holding patchbombs meaning literally one mbox file with a zillion contatenated patches received via email. To be fair to you, it is _not_ the practices of Linux hackers. For one thing, I am not among them. I think it is perfectly reasonable to expect it to produce a single mailbox, like you expected. The primary reason why format-patch --mbox only does one file per patch is because I am too lazy to add a --single-mbox option which does the right thing. This _could_ be fixed, but on the other hand the current one file per patch behaviour is arguably more flexible than always creating a single mbox, and that is what I use as an excuse to justify my laziness ;-). - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git/cogito suggestion: tags with descriptions
Hi Junio! On Mon, Sep 05, 2005 at 12:01:40PM -0700, Junio C Hamano wrote: Zack Brown [EMAIL PROTECTED] writes: It would be great if tags also allowed a brief description to go along with them, that would show up in cg-tag-ls. Then I could seek to a tag that's just an easy-to-type version number, and still have an idea of what's significant about that version because of the descriptive text. Would 'git tag -a' work for you? : siamese; git tag -a -m 'This is to just demonstrate.' test-for-brown : siamese; git cat-file tag test-for-brown object 0516de30e8bdd26086e2a3edd3375981fd0c34d6 type commit tag test-for-brown tagger Junio C Hamano [EMAIL PROTECTED] 1125946805 -0700 This is to just demonstrate. : siamese; I'm not sure. I'm not as familiar with the low-level git commands as I am with cogito. But cogito has a -d option for giving a tag description. I guess what would be closest to what I was thinking about would be this: $ cg-tag -d First draft, everything in place. 0.3 7540e503b9b9c1b03e44ee7fd700c844b2a02224 $ cg-tag-ls 0.1 Initial idea complete f953b71b21a0bea682c2bed91362f2dce2cc204f 0.3 First draft, everything in place. 7540e503b9b9c1b03e44ee7fd700c844b2a02224 $ or something like that. Currently when I do the above cg-tag command, a subsequent cg-tag-ls gives just: $ cg-tag-ls 0.1 f953b71b21a0bea682c2bed91362f2dce2cc204f 0.3 7540e503b9b9c1b03e44ee7fd700c844b2a02224 In fact, I probably wouldn't even be interested in seeing the actual hash key unless I gave a special flag, maybe -f (for full): $ cg-tag-ls 0.1 Initial idea complete 0.3 First draft, everything in place. $ cg-tag-ls -f 0.1 Initial idea complete f953b71b21a0bea682c2bed91362f2dce2cc204f 0.3 First draft, everything in place. 7540e503b9b9c1b03e44ee7fd700c844b2a02224 $ BTW, when will the next issue of GIT traffic appear ;-)? Honestly, I don't know. I seem to be having my hands full just trying to keep Kernel Traffic up-to-date (just caught up today, finally). I really did the first Git Traffic to kind of spread the word about how mind-blowing the whole git development process was. But whether I'll keep on doing it, I don't know. Between Kernel Traffic, my day job, and a few non-Linux projects, I may have my hands full. On the other hand, if someone wanted to volunteer to write Git Traffic, I'd be happy to help them get started. I don't mean you, but perhaps a regular reader of this list would be interested. It seems like there's at least some interest in seeing it continue. :-) Be well, Zack - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Zack Brown - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
patches
Hi,
attached are two patches:
the first fixes some build issues on solaris10/x86 with sunpro (and some
that also happen with gcc), while the second adds a simple way to add
additional search and link paths for curl library and headers.
patrick mauritz
(not on the list, please Cc:)
diff -ur git-core-0.99.4.orig/convert-cache.c git-core-0.99.4/convert-cache.c
--- git-core-0.99.5.orig/convert-cache.c Wed Aug 17 09:55:00 2005
+++ git-core-0.99.5/convert-cache.c Wed Aug 17 09:58:48 2005
@@ -1,4 +1,5 @@
#define _XOPEN_SOURCE /* glibc2 needs this */
+#define __EXTENSIONS__ /* solaris needs this */
#include time.h
#include ctype.h
#include cache.h
diff -ur git-core-0.99.4.orig/ident.c git-core-0.99.4/ident.c
--- git-core-0.99.5.orig/ident.c Wed Aug 17 09:55:00 2005
+++ git-core-0.99.5/ident.c Wed Aug 17 09:57:54 2005
@@ -36,12 +36,13 @@
memcpy(real_email, pw-pw_name, len);
real_email[len++] = '@';
gethostname(real_email + len, sizeof(real_email) - len);
+#ifndef __sun
if (!strchr(real_email+len, '.')) {
len = strlen(real_email);
real_email[len++] = '.';
getdomainname(real_email+len, sizeof(real_email)-len);
}
-
+#endif
/* And set the default date */
datestamp(real_date, sizeof(real_date));
return 0;
--- git-core-0.99.5/Makefile~ Thu Aug 25 03:54:24 2005
+++ git-core-0.99.5/Makefile Tue Sep 6 01:18:32 2005
@@ -146,7 +146,11 @@
endif
endif
endif
+ifeq ($(shell uname -s),SunOS)
+ LIBS += -lsocket
+endif
+
DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'
--- git-core-0.99.5/Makefile~ Tue Sep 6 01:13:29 2005
+++ git-core-0.99.5/MakefileTue Sep 6 01:15:40 2005
@@ -34,7 +34,14 @@
GIT_VERSION = 0.99.5
-CFLAGS = -g -O2 -Wall
+ifndef COPTS
+COPTS = -g -O2 -Wall
+endif
+CFLAGS = $(COPTS)
+ifdef CURLDIR
+CFLAGS+=-I$(CURLDIR)/include
+endif
+
ALL_CFLAGS = $(CFLAGS) $(DEFINES)
prefix = $(HOME)
@@ -172,7 +179,11 @@
git-ssh-pull: rsh.o pull.o
git-ssh-push: rsh.o
+ifdef CURLDIR
+git-http-pull: LIBS += -lcurl -L$(CURLDIR)/lib -R$(CURLDIR)/lib
+else
git-http-pull: LIBS += -lcurl
+endif
git-rev-list: LIBS += $(OPENSSL_LIBSSL)
init-db.o: init-db.c
Re: Tool renames? was Re: First stab at glossary
On 9/6/05, Linus Torvalds [EMAIL PROTECTED] wrote: Grepping for strings. For example, when renaming a binary, the sane way to check that you fixed all users right now is grep old-binary-name *.c *.h *-scripts and you catch all users. Grep knows how to ignore binary files. Try: grep -I git-commit * cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
