* Re: [cvsimport] Import CVS repository from a specified date or branch name
From: Nick Woolley @ 2009-10-23 21:38 UTC (permalink / raw)
To: Klaus Rödel; +Cc: git
In-Reply-To: <4AE160BC.5000608@vipco.de>
Klaus Rödel wrote:
> I have a very large and old (serveral years) cvs repository and I want
> to import this in git.
> For my work it is not nessecary to import all the revision history from
> the cvs repository.
> It is engough to import only the revisions from a specified date or
> branch name of the cvs repo.
>
> Is this possible with git-cvsimport?
I'm not certain if it is possible, if it is I suspect it might require invoking
cvsps first and then reading in the output generated with git-cvsimport, as
Andreas implies.
In any case, the underlying cvsps program is flawed, and in it's current form,
although it seems to work ok for simple situations, I know for a fact that
didn't faithfully reproduce a rather big old CVS repository I tried it on. So if
you're planning on just importing once, and don't need incremental imports, from
my experience I'd suggest you'd fare better using cvs2git:
http://cvs2svn.tigris.org/cvs2git.html
Cheers,
N
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Junio C Hamano @ 2009-10-23 21:26 UTC (permalink / raw)
To: Bernhard Reutner-Fischer; +Cc: vda.linux, busybox, git
In-Reply-To: <20091023210648.GA23122@mx.loc>
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> writes:
> On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>>On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>>on create, 'o' would be --old-archive.
>>
>>FYI this was prompted by:
>>
>>Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
>>
>>diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
>>--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
>>+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
>>@@ -50,4 +50,4 @@ clean:
>> install: all
>> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
>> (cd blt && $(TAR) cf - .) | \
>>- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>>+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
>
> argh, sorry! --no-same-owner of course.
Either way, your change would break non-GNU tar implementations that are
properly POSIX.1, isn't it?
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Kevyn-Alexandre Paré @ 2009-10-23 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, linux-newbie, kernel-janitors, git
In-Reply-To: <7vskd9akv6.fsf@alter.siamese.dyndns.org>
My mistake but I learn a lot from you guys!
I should simply have done:
./scripts/checkpatch.pl --terse --patch
0001-Staging-comedi-driver-fix-coding-style.patch
or
./scripts/checkpatch.pl --terse --patch
0001-Staging-comedi-driver-fix-coding-style.patch
# Since --patch is the default!
No warning to the output, I will change my blog
thx again
kap
On Fri, Oct 23, 2009 at 4:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> On Fri, 23 Oct 2009, Kevyn-Alexandre Paré wrote:
>>
>>> Just before I send my patch I got this error with:
>>> ./scripts/checkpatch.pl --terse --file
>>> 0001-Staging-comedi-driver-fix-coding-style.patch
>>
>> You're using checkpatch --file on a patch. I hope you don't intend your
>> patch to be added to the kernel source as a file, but rather applied to
>> the kernel source, changing other files. (I bet "gcc 0001-Staging*.patch"
>> will get interesting errors, too...) The patch format adds a single
>> character at the beginning of each line to say whether it's a addition, a
>> deletion, or a context line, and the context lines are identified by a
>> space character. This means that a blank context line consists of just
>> this space character, which is therefore a trailing space. We get the same
>> type of complaints when we have expected diff output in our test scripts.
>>
>> I'm kind of surprised that checkpatch doesn't completely blow up when it's
>> expecting a source file and getting a patch (and maybe tell you what
>> you've done). But that's the source of your errors, anyway.
>
> Ah, your analysis is correct. This is a usage error of checkpatch script
> and there is nothing for us to worry about.
>
> Thanks; I also failed to spot --file option when I responded.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Bernhard Reutner-Fischer @ 2009-10-23 21:06 UTC (permalink / raw)
To: vda.linux; +Cc: busybox, git
In-Reply-To: <20091023202524.GE4615@mx.loc>
On Fri, Oct 23, 2009 at 10:25:24PM +0200, Bernhard Reutner-Fischer wrote:
>On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>>on create, 'o' would be --old-archive.
>
>FYI this was prompted by:
>
>Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
>
>diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
>--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
>+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
>@@ -50,4 +50,4 @@ clean:
> install: all
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
> (cd blt && $(TAR) cf - .) | \
>- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
>+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
argh, sorry! --no-same-owner of course.
>Someone should try to ask the git people not to rely on getopt
>permuting options.. xof would be gentle to folks who don't want
>to turn on getopt_long though.
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Junio C Hamano @ 2009-10-23 20:58 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Kevyn-Alexandre Paré, linux-newbie, kernel-janitors, git
In-Reply-To: <alpine.LNX.2.00.0910231621550.14365@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Fri, 23 Oct 2009, Kevyn-Alexandre Paré wrote:
>
>> Just before I send my patch I got this error with:
>> ./scripts/checkpatch.pl --terse --file
>> 0001-Staging-comedi-driver-fix-coding-style.patch
>
> You're using checkpatch --file on a patch. I hope you don't intend your
> patch to be added to the kernel source as a file, but rather applied to
> the kernel source, changing other files. (I bet "gcc 0001-Staging*.patch"
> will get interesting errors, too...) The patch format adds a single
> character at the beginning of each line to say whether it's a addition, a
> deletion, or a context line, and the context lines are identified by a
> space character. This means that a blank context line consists of just
> this space character, which is therefore a trailing space. We get the same
> type of complaints when we have expected diff output in our test scripts.
>
> I'm kind of surprised that checkpatch doesn't completely blow up when it's
> expecting a source file and getting a patch (and maybe tell you what
> you've done). But that's the source of your errors, anyway.
Ah, your analysis is correct. This is a usage error of checkpatch script
and there is nothing for us to worry about.
Thanks; I also failed to spot --file option when I responded.
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Kevyn-Alexandre Paré @ 2009-10-23 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <dc1d0f40910231330n7cc521d0n52aac929c334bc9d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3379 bytes --]
I forgot my .c file
On Fri, Oct 23, 2009 at 4:30 PM, Kevyn-Alexandre Paré
<kevyn.alexandre.pare@gmail.com> wrote:
> Thx junio for that analyse!
>
> So what I understand from what you have said is that the problem is
> not in format-patch since that I see white space from git show $commit
> ?!:
>
> history: I was trying to remove coding style problem in
> drivers/staging/comedi/drivers/pcl726.c
>
> ./scripts/checkpatch.pl --terse --file
> drivers/staging/comedi/drivers/pcl726.c #### NO warning after
> removing problems
> ### git commit -a
> # was done after that
> ### git format-patch -s -n master..pcl726
>
> kapare@vostro:~/linux-kernel-patch/linux-2.6$ git show $commit >
> TEST.git.show.commit #### see whitespace in vim
> kapare@vostro:~/linux-kernel-patch/linux-2.6$ ./scripts/checkpatch.pl
> --terse --file TEST.git.show.commit
> TEST:19: ERROR: trailing whitespace
> TEST:27: ERROR: trailing whitespace
> TEST:35: ERROR: trailing whitespace
> TEST:45: ERROR: trailing whitespace
> TEST:55: ERROR: trailing whitespace
> TEST:60: ERROR: trailing whitespace
> TEST:67: ERROR: trailing whitespace
> TEST:69: ERROR: trailing whitespace
> TEST:80: ERROR: trailing whitespace
> TEST:106: ERROR: trailing whitespace
> TEST:113: ERROR: trailing whitespace
>
> So what am I doing wrong? Any clues? see attachment you ask
>
> thx
>
> kap
>
> On Fri, Oct 23, 2009 at 3:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
>>
>>> Just before I send my patch I got this error with:
>>> ./scripts/checkpatch.pl --terse --file
>>> 0001-Staging-comedi-driver-fix-coding-style.patch
>>>
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
>>>
>>> I have done a step by step explanation of what I have done:
>>> http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html
>>>
>>> It seem to me that the whitespace are added after I do this command:
>>> git format-patch -s -n master..mybranch
>>
>> "The whitespace are added after..." sounds to me that what you committed
>> were checkpatch compliant, and format-patch somehow broke it. If that is
>> the case we need to fix format-patch.
>>
>> Please check if "git show $commit" output for the commit that corresponds
>> to the "[Staging] comedi driver: fix coding style" patch has trailing
>> whitespaces. That is what you committed.
>>
>> If there already is whitespace breakage in what you committed, then we do
>> not have to blame format-patch and look for bugs in it to fix.
>>
>> Otherwise, please send 0001-*.patch (output from format-patch) and output
>> from that "git show $commit" as separate attachments, so that we can debug
>> and fix format-patch.
>>
>> Thanks.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.linux-learn.org/faqs
>>
>
[-- Attachment #2: pcl726.c --]
[-- Type: text/x-csrc, Size: 9864 bytes --]
/*
comedi/drivers/pcl726.c
hardware driver for Advantech cards:
card: PCL-726, PCL-727, PCL-728
driver: pcl726, pcl727, pcl728
and for ADLink cards:
card: ACL-6126, ACL-6128
driver: acl6126, acl6128
COMEDI - Linux Control and Measurement Device Interface
Copyright (C) 1998 David A. Schleef <ds@schleef.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/*
Driver: pcl726
Description: Advantech PCL-726 & compatibles
Author: ds
Status: untested
Devices: [Advantech] PCL-726 (pcl726), PCL-727 (pcl727), PCL-728 (pcl728),
[ADLink] ACL-6126 (acl6126), ACL-6128 (acl6128)
Interrupts are not supported.
Options for PCL-726:
[0] - IO Base
[2]...[7] - D/A output range for channel 1-6:
0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
4: 4-20mA, 5: unknown (external reference)
Options for PCL-727:
[0] - IO Base
[2]...[13] - D/A output range for channel 1-12:
0: 0-5V, 1: 0-10V, 2: +/-5V,
3: 4-20mA
Options for PCL-728 and ACL-6128:
[0] - IO Base
[2], [3] - D/A output range for channel 1 and 2:
0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
4: 4-20mA, 5: 0-20mA
Options for ACL-6126:
[0] - IO Base
[1] - IRQ (0=disable, 3, 5, 6, 7, 9, 10, 11, 12, 15) (currently ignored)
[2]...[7] - D/A output range for channel 1-6:
0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
4: 4-20mA
*/
/*
Thanks to Circuit Specialists for having programming info (!) on
their web page. (http://www.cir.com/)
*/
#include "../comedidev.h"
#include <linux/ioport.h>
#undef ACL6126_IRQ /* no interrupt support (yet) */
#define PCL726_SIZE 16
#define PCL727_SIZE 32
#define PCL728_SIZE 8
#define PCL726_DAC0_HI 0
#define PCL726_DAC0_LO 1
#define PCL726_DO_HI 12
#define PCL726_DO_LO 13
#define PCL726_DI_HI 14
#define PCL726_DI_LO 15
#define PCL727_DO_HI 24
#define PCL727_DO_LO 25
#define PCL727_DI_HI 0
#define PCL727_DI_LO 1
static const struct comedi_lrange range_4_20mA = { 1, {RANGE_mA(4, 20)} };
static const struct comedi_lrange range_0_20mA = { 1, {RANGE_mA(0, 20)} };
static const struct comedi_lrange *const rangelist_726[] = {
&range_unipolar5, &range_unipolar10,
&range_bipolar5, &range_bipolar10,
&range_4_20mA, &range_unknown
};
static const struct comedi_lrange *const rangelist_727[] = {
&range_unipolar5, &range_unipolar10,
&range_bipolar5,
&range_4_20mA
};
static const struct comedi_lrange *const rangelist_728[] = {
&range_unipolar5, &range_unipolar10,
&range_bipolar5, &range_bipolar10,
&range_4_20mA, &range_0_20mA
};
static int pcl726_attach(struct comedi_device *dev,
struct comedi_devconfig *it);
static int pcl726_detach(struct comedi_device *dev);
struct pcl726_board {
const char *name; /* driver name */
int n_aochan; /* num of D/A chans */
int num_of_ranges; /* num of ranges */
unsigned int IRQbits; /* allowed interrupts */
unsigned int io_range; /* len of IO space */
char have_dio; /* 1=card have DI/DO ports */
int di_hi; /* ports for DI/DO operations */
int di_lo;
int do_hi;
int do_lo;
const struct comedi_lrange *const *range_type_list;
/* list of supported ranges */
};
static const struct pcl726_board boardtypes[] = {
{"pcl726", 6, 6, 0x0000, PCL726_SIZE, 1,
PCL726_DI_HI, PCL726_DI_LO, PCL726_DO_HI, PCL726_DO_LO,
&rangelist_726[0],},
{"pcl727", 12, 4, 0x0000, PCL727_SIZE, 1,
PCL727_DI_HI, PCL727_DI_LO, PCL727_DO_HI, PCL727_DO_LO,
&rangelist_727[0],},
{"pcl728", 2, 6, 0x0000, PCL728_SIZE, 0,
0, 0, 0, 0,
&rangelist_728[0],},
{"acl6126", 6, 5, 0x96e8, PCL726_SIZE, 1,
PCL726_DI_HI, PCL726_DI_LO, PCL726_DO_HI, PCL726_DO_LO,
&rangelist_726[0],},
{"acl6128", 2, 6, 0x0000, PCL728_SIZE, 0,
0, 0, 0, 0,
&rangelist_728[0],},
};
#define n_boardtypes (sizeof(boardtypes)/sizeof(struct pcl726_board))
#define this_board ((const struct pcl726_board *)dev->board_ptr)
static struct comedi_driver driver_pcl726 = {
.driver_name = "pcl726",
.module = THIS_MODULE,
.attach = pcl726_attach,
.detach = pcl726_detach,
.board_name = &boardtypes[0].name,
.num_names = n_boardtypes,
.offset = sizeof(struct pcl726_board),
};
COMEDI_INITCLEANUP(driver_pcl726);
struct pcl726_private {
int bipolar[12];
const struct comedi_lrange *rangelist[12];
unsigned int ao_readback[12];
};
#define devpriv ((struct pcl726_private *)dev->private)
static int pcl726_ao_insn(struct comedi_device *dev, struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
int hi, lo;
int n;
int chan = CR_CHAN(insn->chanspec);
for (n = 0; n < insn->n; n++) {
lo = data[n] & 0xff;
hi = (data[n] >> 8) & 0xf;
if (devpriv->bipolar[chan])
hi ^= 0x8;
/*
* the programming info did not say which order
* to write bytes. switch the order of the next
* two lines if you get glitches.
*/
outb(hi, dev->iobase + PCL726_DAC0_HI + 2 * chan);
outb(lo, dev->iobase + PCL726_DAC0_LO + 2 * chan);
devpriv->ao_readback[chan] = data[n];
}
return n;
}
static int pcl726_ao_insn_read(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
int chan = CR_CHAN(insn->chanspec);
int n;
for (n = 0; n < insn->n; n++)
data[n] = devpriv->ao_readback[chan];
return n;
}
static int pcl726_di_insn_bits(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
if (insn->n != 2)
return -EINVAL;
data[1] = inb(dev->iobase + this_board->di_lo) |
(inb(dev->iobase + this_board->di_hi) << 8);
return 2;
}
static int pcl726_do_insn_bits(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
if (insn->n != 2)
return -EINVAL;
if (data[0]) {
s->state &= ~data[0];
s->state |= data[0] & data[1];
}
if (data[1] & 0x00ff)
outb(s->state & 0xff, dev->iobase + this_board->do_lo);
if (data[1] & 0xff00)
outb((s->state >> 8), dev->iobase + this_board->do_hi);
data[1] = s->state;
return 2;
}
static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
{
struct comedi_subdevice *s;
unsigned long iobase;
unsigned int iorange;
int ret, i;
#ifdef ACL6126_IRQ
unsigned int irq;
#endif
iobase = it->options[0];
iorange = this_board->io_range;
printk(KERN_WARNING, "comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
this_board->name, iobase);
if (!request_region(iobase, iorange, "pcl726")) {
printk(KERN_WARNING, "I/O port conflict\n");
return -EIO;
}
dev->iobase = iobase;
dev->board_name = this_board->name;
ret = alloc_private(dev, sizeof(struct pcl726_private));
if (ret < 0)
return -ENOMEM;
for (i = 0; i < 12; i++) {
devpriv->bipolar[i] = 0;
devpriv->rangelist[i] = &range_unknown;
}
#ifdef ACL6126_IRQ
irq = 0;
if (boardtypes[board].IRQbits != 0) { /* board support IRQ */
irq = it->options[1];
devpriv->first_chan = 2;
if (irq) { /* we want to use IRQ */
if (((1 << irq) & boardtypes[board].IRQbits) == 0) {
printk(KERN_WARNING,
", IRQ %d is out of allowed range,"
" DISABLING IT", irq);
irq = 0; /* Bad IRQ */
} else {
if (request_irq(irq, interrupt_pcl818, 0,
"pcl726", dev)) {
printk(KERN_WARNING,
", unable to allocate IRQ %d,"
" DISABLING IT", irq);
irq = 0; /* Can't use IRQ */
} else {
printk(", irq=%d", irq);
}
}
}
}
dev->irq = irq;
#endif
printk("\n");
ret = alloc_subdevices(dev, 3);
if (ret < 0)
return ret;
s = dev->subdevices + 0;
/* ao */
s->type = COMEDI_SUBD_AO;
s->subdev_flags = SDF_WRITABLE | SDF_GROUND;
s->n_chan = this_board->n_aochan;
s->maxdata = 0xfff;
s->len_chanlist = 1;
s->insn_write = pcl726_ao_insn;
s->insn_read = pcl726_ao_insn_read;
s->range_table_list = devpriv->rangelist;
for (i = 0; i < this_board->n_aochan; i++) {
int j;
j = it->options[2 + 1];
if ((j < 0) || (j >= this_board->num_of_ranges)) {
printk
("Invalid range for channel %d! Must be 0<=%d<%d\n",
i, j, this_board->num_of_ranges - 1);
j = 0;
}
devpriv->rangelist[i] = this_board->range_type_list[j];
if (devpriv->rangelist[i]->range[0].min ==
-devpriv->rangelist[i]->range[0].max)
devpriv->bipolar[i] = 1; /* bipolar range */
}
s = dev->subdevices + 1;
/* di */
if (!this_board->have_dio) {
s->type = COMEDI_SUBD_UNUSED;
} else {
s->type = COMEDI_SUBD_DI;
s->subdev_flags = SDF_READABLE | SDF_GROUND;
s->n_chan = 16;
s->maxdata = 1;
s->len_chanlist = 1;
s->insn_bits = pcl726_di_insn_bits;
s->range_table = &range_digital;
}
s = dev->subdevices + 2;
/* do */
if (!this_board->have_dio) {
s->type = COMEDI_SUBD_UNUSED;
} else {
s->type = COMEDI_SUBD_DO;
s->subdev_flags = SDF_WRITABLE | SDF_GROUND;
s->n_chan = 16;
s->maxdata = 1;
s->len_chanlist = 1;
s->insn_bits = pcl726_do_insn_bits;
s->range_table = &range_digital;
}
return 0;
}
static int pcl726_detach(struct comedi_device *dev)
{
/* printk("comedi%d: pcl726: remove\n",dev->minor); */
#ifdef ACL6126_IRQ
if (dev->irq)
free_irq(dev->irq, dev);
#endif
if (dev->iobase)
release_region(dev->iobase, this_board->io_range);
return 0;
}
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Daniel Barkalow @ 2009-10-23 20:33 UTC (permalink / raw)
To: Kevyn-Alexandre Paré; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <dc1d0f40910231146y14028f4el9753debdf334103@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1118 bytes --]
On Fri, 23 Oct 2009, Kevyn-Alexandre Paré wrote:
> Hi,
>
> Just before I send my patch I got this error with:
> ./scripts/checkpatch.pl --terse --file
> 0001-Staging-comedi-driver-fix-coding-style.patch
You're using checkpatch --file on a patch. I hope you don't intend your
patch to be added to the kernel source as a file, but rather applied to
the kernel source, changing other files. (I bet "gcc 0001-Staging*.patch"
will get interesting errors, too...) The patch format adds a single
character at the beginning of each line to say whether it's a addition, a
deletion, or a context line, and the context lines are identified by a
space character. This means that a blank context line consists of just
this space character, which is therefore a trailing space. We get the same
type of complaints when we have expected diff output in our test scripts.
I'm kind of surprised that checkpatch doesn't completely blow up when it's
expecting a source file and getting a patch (and maybe tell you what
you've done). But that's the source of your errors, anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Kevyn-Alexandre Paré @ 2009-10-23 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <7v8wf1c2h9.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3149 bytes --]
Thx junio for that analyse!
So what I understand from what you have said is that the problem is
not in format-patch since that I see white space from git show $commit
?!:
history: I was trying to remove coding style problem in
drivers/staging/comedi/drivers/pcl726.c
./scripts/checkpatch.pl --terse --file
drivers/staging/comedi/drivers/pcl726.c #### NO warning after
removing problems
### git commit -a
# was done after that
### git format-patch -s -n master..pcl726
kapare@vostro:~/linux-kernel-patch/linux-2.6$ git show $commit >
TEST.git.show.commit #### see whitespace in vim
kapare@vostro:~/linux-kernel-patch/linux-2.6$ ./scripts/checkpatch.pl
--terse --file TEST.git.show.commit
TEST:19: ERROR: trailing whitespace
TEST:27: ERROR: trailing whitespace
TEST:35: ERROR: trailing whitespace
TEST:45: ERROR: trailing whitespace
TEST:55: ERROR: trailing whitespace
TEST:60: ERROR: trailing whitespace
TEST:67: ERROR: trailing whitespace
TEST:69: ERROR: trailing whitespace
TEST:80: ERROR: trailing whitespace
TEST:106: ERROR: trailing whitespace
TEST:113: ERROR: trailing whitespace
So what am I doing wrong? Any clues? see attachment you ask
thx
kap
On Fri, Oct 23, 2009 at 3:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
>
>> Just before I send my patch I got this error with:
>> ./scripts/checkpatch.pl --terse --file
>> 0001-Staging-comedi-driver-fix-coding-style.patch
>>
>> 0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
>> 0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
>> 0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
>> 0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
>>
>> I have done a step by step explanation of what I have done:
>> http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html
>>
>> It seem to me that the whitespace are added after I do this command:
>> git format-patch -s -n master..mybranch
>
> "The whitespace are added after..." sounds to me that what you committed
> were checkpatch compliant, and format-patch somehow broke it. If that is
> the case we need to fix format-patch.
>
> Please check if "git show $commit" output for the commit that corresponds
> to the "[Staging] comedi driver: fix coding style" patch has trailing
> whitespaces. That is what you committed.
>
> If there already is whitespace breakage in what you committed, then we do
> not have to blame format-patch and look for bugs in it to fix.
>
> Otherwise, please send 0001-*.patch (output from format-patch) and output
> from that "git show $commit" as separate attachments, so that we can debug
> and fix format-patch.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
>
[-- Attachment #2: 0001-Staging-comedi-driver-fix-coding-style.patch --]
[-- Type: text/x-patch, Size: 4017 bytes --]
From 2313270068581ff425140c1f361b26edd096658f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Kevyn-Alexandre=20Par=C3=A9?= <kevyn.alexandre.pare@gmail.com>
Date: Fri, 23 Oct 2009 00:59:40 -0400
Subject: [PATCH 1/1] Staging: comedi driver: fix coding style
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com>
---
drivers/staging/comedi/drivers/pcl726.c | 41 +++++++++++++++----------------
1 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/comedi/drivers/pcl726.c b/drivers/staging/comedi/drivers/pcl726.c
index ccadd09..6208bca 100644
--- a/drivers/staging/comedi/drivers/pcl726.c
+++ b/drivers/staging/comedi/drivers/pcl726.c
@@ -39,27 +39,27 @@ Interrupts are not supported.
Options for PCL-726:
[0] - IO Base
[2]...[7] - D/A output range for channel 1-6:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA, 5: unknown (external reference)
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA, 5: unknown (external reference)
Options for PCL-727:
[0] - IO Base
[2]...[13] - D/A output range for channel 1-12:
- 0: 0-5V, 1: 0-10V, 2: +/-5V,
- 3: 4-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V,
+ 3: 4-20mA
Options for PCL-728 and ACL-6128:
[0] - IO Base
[2], [3] - D/A output range for channel 1 and 2:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA, 5: 0-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA, 5: 0-20mA
Options for ACL-6126:
[0] - IO Base
[1] - IRQ (0=disable, 3, 5, 6, 7, 9, 10, 11, 12, 15) (currently ignored)
[2]...[7] - D/A output range for channel 1-6:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA
*/
/*
@@ -127,7 +127,8 @@ struct pcl726_board {
int di_lo;
int do_hi;
int do_lo;
- const struct comedi_lrange *const *range_type_list; /* list of supported ranges */
+ const struct comedi_lrange *const *range_type_list;
+ /* list of supported ranges */
};
static const struct pcl726_board boardtypes[] = {
@@ -204,9 +205,8 @@ static int pcl726_ao_insn_read(struct comedi_device *dev,
int chan = CR_CHAN(insn->chanspec);
int n;
- for (n = 0; n < insn->n; n++) {
+ for (n = 0; n < insn->n; n++)
data[n] = devpriv->ao_readback[chan];
- }
return n;
}
@@ -256,10 +256,10 @@ static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
iobase = it->options[0];
iorange = this_board->io_range;
- printk("comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
+ printk(KERN_WARNING, "comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
this_board->name, iobase);
if (!request_region(iobase, iorange, "pcl726")) {
- printk("I/O port conflict\n");
+ printk(KERN_WARNING, "I/O port conflict\n");
return -EIO;
}
@@ -283,16 +283,16 @@ static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
devpriv->first_chan = 2;
if (irq) { /* we want to use IRQ */
if (((1 << irq) & boardtypes[board].IRQbits) == 0) {
- printk
- (", IRQ %d is out of allowed range, DISABLING IT",
- irq);
+ printk(KERN_WARNING,
+ ", IRQ %d is out of allowed range,"
+ " DISABLING IT", irq);
irq = 0; /* Bad IRQ */
} else {
if (request_irq(irq, interrupt_pcl818, 0,
"pcl726", dev)) {
- printk
- (", unable to allocate IRQ %d, DISABLING IT",
- irq);
+ printk(KERN_WARNING,
+ ", unable to allocate IRQ %d,"
+ " DISABLING IT", irq);
irq = 0; /* Can't use IRQ */
} else {
printk(", irq=%d", irq);
@@ -372,9 +372,8 @@ static int pcl726_detach(struct comedi_device *dev)
/* printk("comedi%d: pcl726: remove\n",dev->minor); */
#ifdef ACL6126_IRQ
- if (dev->irq) {
+ if (dev->irq)
free_irq(dev->irq, dev);
- }
#endif
if (dev->iobase)
--
1.6.0.4
[-- Attachment #3: TEST.git.show.commit --]
[-- Type: application/octet-stream, Size: 3652 bytes --]
commit 2313270068581ff425140c1f361b26edd096658f
Author: Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com>
Date: Fri Oct 23 00:59:40 2009 -0400
Staging: comedi driver: fix coding style
diff --git a/drivers/staging/comedi/drivers/pcl726.c b/drivers/staging/comedi/drivers/pcl726.c
index ccadd09..6208bca 100644
--- a/drivers/staging/comedi/drivers/pcl726.c
+++ b/drivers/staging/comedi/drivers/pcl726.c
@@ -39,27 +39,27 @@ Interrupts are not supported.
Options for PCL-726:
[0] - IO Base
[2]...[7] - D/A output range for channel 1-6:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA, 5: unknown (external reference)
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA, 5: unknown (external reference)
Options for PCL-727:
[0] - IO Base
[2]...[13] - D/A output range for channel 1-12:
- 0: 0-5V, 1: 0-10V, 2: +/-5V,
- 3: 4-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V,
+ 3: 4-20mA
Options for PCL-728 and ACL-6128:
[0] - IO Base
[2], [3] - D/A output range for channel 1 and 2:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA, 5: 0-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA, 5: 0-20mA
Options for ACL-6126:
[0] - IO Base
[1] - IRQ (0=disable, 3, 5, 6, 7, 9, 10, 11, 12, 15) (currently ignored)
[2]...[7] - D/A output range for channel 1-6:
- 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
- 4: 4-20mA
+ 0: 0-5V, 1: 0-10V, 2: +/-5V, 3: +/-10V,
+ 4: 4-20mA
*/
/*
@@ -127,7 +127,8 @@ struct pcl726_board {
int di_lo;
int do_hi;
int do_lo;
- const struct comedi_lrange *const *range_type_list; /* list of supported ranges */
+ const struct comedi_lrange *const *range_type_list;
+ /* list of supported ranges */
};
static const struct pcl726_board boardtypes[] = {
@@ -204,9 +205,8 @@ static int pcl726_ao_insn_read(struct comedi_device *dev,
int chan = CR_CHAN(insn->chanspec);
int n;
- for (n = 0; n < insn->n; n++) {
+ for (n = 0; n < insn->n; n++)
data[n] = devpriv->ao_readback[chan];
- }
return n;
}
@@ -256,10 +256,10 @@ static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
iobase = it->options[0];
iorange = this_board->io_range;
- printk("comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
+ printk(KERN_WARNING, "comedi%d: pcl726: board=%s, 0x%03lx ", dev->minor,
this_board->name, iobase);
if (!request_region(iobase, iorange, "pcl726")) {
- printk("I/O port conflict\n");
+ printk(KERN_WARNING, "I/O port conflict\n");
return -EIO;
}
@@ -283,16 +283,16 @@ static int pcl726_attach(struct comedi_device *dev, struct comedi_devconfig *it)
devpriv->first_chan = 2;
if (irq) { /* we want to use IRQ */
if (((1 << irq) & boardtypes[board].IRQbits) == 0) {
- printk
- (", IRQ %d is out of allowed range, DISABLING IT",
- irq);
+ printk(KERN_WARNING,
+ ", IRQ %d is out of allowed range,"
+ " DISABLING IT", irq);
irq = 0; /* Bad IRQ */
} else {
if (request_irq(irq, interrupt_pcl818, 0,
"pcl726", dev)) {
- printk
- (", unable to allocate IRQ %d, DISABLING IT",
- irq);
+ printk(KERN_WARNING,
+ ", unable to allocate IRQ %d,"
+ " DISABLING IT", irq);
irq = 0; /* Can't use IRQ */
} else {
printk(", irq=%d", irq);
@@ -372,9 +372,8 @@ static int pcl726_detach(struct comedi_device *dev)
/* printk("comedi%d: pcl726: remove\n",dev->minor); */
#ifdef ACL6126_IRQ
- if (dev->irq) {
+ if (dev->irq)
free_irq(dev->irq, dev);
- }
#endif
if (dev->iobase)
^ permalink raw reply related
* Re: ks/precompute-completion
From: Sverre Rabbelier @ 2009-10-23 20:22 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, gitzilla, git, Shawn O. Pearce, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <m3d44deu93.fsf@localhost.localdomain>
Heya,
On Fri, Oct 23, 2009 at 15:20, Jakub Narebski <jnareb@gmail.com> wrote:
> (and not make this target part of "make all")
But that I can already do through 'make contrib/completion/Makefile',
what I want is to not have to worry about doing that whenever I update
my git install (that is, the same way as it was before it became
pre-computed).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] tar: on extract, -o is --no-same-owner
From: Bernhard Reutner-Fischer @ 2009-10-23 20:25 UTC (permalink / raw)
To: vda.linux; +Cc: busybox, git
In-Reply-To: <1256328943-22136-1-git-send-email-rep.dot.nop@gmail.com>
On Fri, Oct 23, 2009 at 10:15:43PM +0200, Bernhard Reutner-Fischer wrote:
>GNU tar-1.22 handles 'o' as no-same-owner only on extract,
>on create, 'o' would be --old-archive.
FYI this was prompted by:
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
diff -rdup git-1.6.5.oorig/templates/Makefile git-1.6.5/templates/Makefile
--- git-1.6.5.oorig/templates/Makefile 2009-10-11 03:42:04.000000000 +0200
+++ git-1.6.5/templates/Makefile 2009-10-23 21:43:06.000000000 +0200
@@ -50,4 +50,4 @@ clean:
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
- (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xfo -)
+ (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) x --no-numeric-owner -f -)
Someone should try to ask the git people not to rely on getopt
permuting options.. xof would be gentle to folks who don't want
to turn on getopt_long though.
cheers,
^ permalink raw reply
* Re: ks/precompute-completion
From: Jakub Narebski @ 2009-10-23 20:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, gitzilla, git, Shawn O. Pearce, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <7v1vktc1uk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
> > This is my main concern, adding 'bash_completion' as a target to all:
> > would be ok; why would 'make clean' break it? As long as you don't add
> > "make -C contrib/completion clean' to the main clean target there's no
> > problem?
>
> "make clean" should remove it, because it is a normal build product,
> if you make your "make all" build completion scripts.
>
> The word _should_ is used in the RFC2119 sense: there may exist valid
> reasons in particular circumstances to ignore a particular item, but the
> full implications must be understood and carefully weighed before choosing
> a different course.
If we take similar approach to the way gitweb can be build to the bash
completion script, which means building it via
make contrib/completion/git-completion.bash
(and not make this target part of "make all"), then there is, I think,
no reason for "make clean" to remove it, isn't it?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [cvsimport] Import CVS repository from a specified date or branch name
From: Andreas Schwab @ 2009-10-23 20:10 UTC (permalink / raw)
To: Klaus Rödel; +Cc: git
In-Reply-To: <4AE160BC.5000608@vipco.de>
Klaus Rödel <klaus.roedel@vipco.de> writes:
> I have a very large and old (serveral years) cvs repository and I want to
> import this in git.
> For my work it is not nessecary to import all the revision history from
> the cvs repository.
> It is engough to import only the revisions from a specified date or branch
> name of the cvs repo.
>
> Is this possible with git-cvsimport?
> If yes, how?
You may be able to do that by passing the right arguments to cvsps.
From cvsps --help:
-d <date1> -d <date2> if just one date specified, show
revisions newer than date1. If two dates specified,
show revisions between two dates.
-b <branch> restrict output to patch sets affecting history of branch
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: ks/precompute-completion
From: Sverre Rabbelier @ 2009-10-23 20:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: gitzilla, git, Shawn O. Pearce, Kirill Smelkov, Stephen Boyd
In-Reply-To: <7v1vktc1uk.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Oct 23, 2009 at 15:05, Junio C Hamano <gitster@pobox.com> wrote:
> "make clean" should remove it, because it is a normal build product,
> if you make your "make all" build completion scripts.
Hmm, I guess that's fair enough, if you 'make clean' you want all
build products to be removed; this problem would be solved by
installing the completion script in the share dir, that way it doens't
matter if 'make clean' removes the one in ~/code/git, as long as the
one in ~/share/git-completion remains.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: ks/precompute-completion
From: Junio C Hamano @ 2009-10-23 20:05 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: gitzilla, git, Shawn O. Pearce, Kirill Smelkov, Stephen Boyd
In-Reply-To: <fabb9a1e0910231216j2a024ac5mf5b5ccb5322722f8@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> This is my main concern, adding 'bash_completion' as a target to all:
> would be ok; why would 'make clean' break it? As long as you don't add
> "make -C contrib/completion clean' to the main clean target there's no
> problem?
"make clean" should remove it, because it is a normal build product,
if you make your "make all" build completion scripts.
The word _should_ is used in the RFC2119 sense: there may exist valid
reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing
a different course.
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Junio C Hamano @ 2009-10-23 19:52 UTC (permalink / raw)
To: Kevyn-Alexandre Paré; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <dc1d0f40910231146y14028f4el9753debdf334103@mail.gmail.com>
Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
> Just before I send my patch I got this error with:
> ./scripts/checkpatch.pl --terse --file
> 0001-Staging-comedi-driver-fix-coding-style.patch
>
> 0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
> 0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
> 0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
> 0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
>
> I have done a step by step explanation of what I have done:
> http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html
>
> It seem to me that the whitespace are added after I do this command:
> git format-patch -s -n master..mybranch
"The whitespace are added after..." sounds to me that what you committed
were checkpatch compliant, and format-patch somehow broke it. If that is
the case we need to fix format-patch.
Please check if "git show $commit" output for the commit that corresponds
to the "[Staging] comedi driver: fix coding style" patch has trailing
whitespaces. That is what you committed.
If there already is whitespace breakage in what you committed, then we do
not have to blame format-patch and look for bugs in it to fix.
Otherwise, please send 0001-*.patch (output from format-patch) and output
from that "git show $commit" as separate attachments, so that we can debug
and fix format-patch.
Thanks.
^ permalink raw reply
* Re: Write and Submit Your First Kernel Patch
From: Michal Nazarewicz @ 2009-10-23 19:41 UTC (permalink / raw)
To: Kevyn-Alexandre Paré; +Cc: linux-newbie, kernel-janitors, git
In-Reply-To: <dc1d0f40910231219l600d3579i57c7580fe798d445@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
>> Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
>>> 0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
>>>
>>> I have done a step by step explanation of what I have done:
>>> http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html>>
>>> It seem to me that the whitespace are added after I do this command:
>>> git format-patch -s -n master..mybranch
> On Fri, Oct 23, 2009 at 3:13 PM, Michal Nazarewicz <mina86@tlen.pl> wrote:
>> Do "git rebase --whitespace=fix master" and git will try to fix whitespaces.
Kevyn-Alexandre Paré <kevyn.alexandre.pare@gmail.com> writes:
> thx Michal,
>
> But the problem remain:
If I'm not mistaken "git rebase --whitespace=fix master" should do the
trick. I'm out of good ideas if it does not. Best I can advice is to
fix the patch by hand -- just edit it in some decent editor and remove
trailing whitespaces from those lines.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: requesting info page (and pdf) doc releases
From: Sebastian Pipping @ 2009-10-23 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rustom Mody, git, Robin H. Johnson
In-Reply-To: <7vtyxqaqg5.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Rustom Mody <rustompmody@gmail.com> writes:
>
>> On Fri, Oct 23, 2009 at 2:11 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>>> would be nice to get info pages (and pdf) doc releases in addition to
>>> html and man pages. i imagine such a change to the release machine
>>> should not be too hard to integrate. we could use it in gentoo.
>> +1
>> Why only gentoo? I would use it on ubuntu or windows as well
>
> As I understand it, Gentoo is supposed to build everything from the source
> anyway, you would not want to use pregenerated info nor pdf, no? You
> shouldn't be using pregenerated html nor man for that matter...
With "compiling" documentation things are a bit different.
Simplified, in contrast to source code compiling documentation leads to
the same results on all machines while sources produces lots of
different results depending on the configuration of the machine ("use
flags", compile flags, versions of linked libraries, ..) which differ
heavily from one machine to another.
Generating documentation downstream means more dependencies for us
without any advantages that I would be aware of. In case of dblatex the
dependencies get quite extreme actually :-) So we thought why not just
ask for it if you provide similar things already.
> FWIW, you can already say "make info" and "make pdf" yourselves if you
> have necessary toolchains installed. Integration is not an issue.
We use make info at the moment. (On a sidenote I hope you get it
working with the latest asciidoc again. See my earlier mail on this list.)
> Neither my primary development box (Debian, which I would test before
> pushing things out) nor the machine at k.org I use for the final sanity
> check (FC11, on which the documents are automatically generated) has
> dblatex nor docbook2x installed. I am not particularly enthused about
> installing a lot of dependencies for these packages on my machine. I do
> not want to bother k.org admins who are already overloaded to install
> these on their machines either.
I see, thanks for your explanation.
Sebastian
^ permalink raw reply
* Re: ks/precompute-completion
From: Sverre Rabbelier @ 2009-10-23 19:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: gitzilla, git, Shawn O. Pearce, Kirill Smelkov, Stephen Boyd
In-Reply-To: <7vd44eaqc5.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Oct 23, 2009 at 13:59, Junio C Hamano <gitster@pobox.com> wrote:
> 1. The series will break your rc script (either $HOME/.bashrc, or
> system-side) that sources $git/contrib/completion/git-completion.bash
> because it has to be built; having "make" generate it may alleviate
> the issue, but "make clean" will break it again, so it is not
> something you can solve in any way other than changing your setting.
This is my main concern, adding 'bash_completion' as a target to all:
would be ok; why would 'make clean' break it? As long as you don't add
"make -C contrib/completion clean' to the main clean target there's no
problem?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: ks/precompute-completion
From: Junio C Hamano @ 2009-10-23 18:59 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: gitzilla, git, Shawn O. Pearce, Junio C Hamano, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <fabb9a1e0910231127i3ab469qebdc17168a58f22a@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Ah, no, I meant that as part of my semi-regular git update (during
> which I do 'make && make install') I want to have up-to-date bash
> completion, preferably installed somewhere system-wide; currently I am
> forced to have a 'source
> /home/sverre/code/git/contrib/completion/git-completion.bash' in my
> .bashrc,..
If you have enough privilege to run 'make && make install' regularly into
a system-wide place, I presume you can have a system-wide rc that sources
/home/sverre/code/git/contrib/completion/git-completion.bash, no?
I think there are two issues.
1. The series will break your rc script (either $HOME/.bashrc, or
system-side) that sources $git/contrib/completion/git-completion.bash
because it has to be built; having "make" generate it may alleviate
the issue, but "make clean" will break it again, so it is not
something you can solve in any way other than changing your setting.
2. Some people have been expecting "make install" not to install the bash
completion anywhere.
So perhaps "make && make install-contrib"?
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Junio C Hamano @ 2009-10-23 18:57 UTC (permalink / raw)
To: Thomas Rast; +Cc: Eugene Sajine, git
In-Reply-To: <200910231034.09747.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano wrote:
>> Thomas Rast <trast@student.ethz.ch> writes:
>>
>> > @@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
>> > printf("%s\n", find_unique_abbrev(sha1, abbrev));
>> > return;
>> > }
>> > - die("cannot describe '%s'", sha1_to_hex(sha1));
>> > + if (unannotated_cnt)
>> > + die("cannot describe '%s'"
>> > + " with only\nannotated tags. Try --tags.",
>>
>> Did you mean UNannotated tags here?
>
> No, but I think I see where the misunderstanding came from.
>
> This code path means that we did not find a tag to describe with, but
> we counted some unannotated tags (and because of how the counting
> logic is wrapped, this only triggers when neither --all nor --tags are
> in effect).
I think I read the code right ;-).
> So I wanted it to say "it is impossible to describe this with the tags
> you told me to use", which in this case are the annotated ones.
The way I read it was "it is impossible to describe it in the way you told
me to, when the tags you have are only unannotated kind."
> However, it could be written e.g.
>
> No annotated tags can describe '%s'. However, there were
> unannotated tags: try --tags.
Sounds better.
^ permalink raw reply
* Re: requesting info page (and pdf) doc releases
From: Junio C Hamano @ 2009-10-23 18:57 UTC (permalink / raw)
To: Rustom Mody; +Cc: Sebastian Pipping, git
In-Reply-To: <f46c52560910221513w1cb19949lfa05ef964987d809@mail.gmail.com>
Rustom Mody <rustompmody@gmail.com> writes:
> On Fri, Oct 23, 2009 at 2:11 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>>
>> would be nice to get info pages (and pdf) doc releases in addition to
>> html and man pages. i imagine such a change to the release machine
>> should not be too hard to integrate. we could use it in gentoo.
>
> +1
> Why only gentoo? I would use it on ubuntu or windows as well
As I understand it, Gentoo is supposed to build everything from the source
anyway, you would not want to use pregenerated info nor pdf, no? You
shouldn't be using pregenerated html nor man for that matter...
FWIW, you can already say "make info" and "make pdf" yourselves if you
have necessary toolchains installed. Integration is not an issue.
Neither my primary development box (Debian, which I would test before
pushing things out) nor the machine at k.org I use for the final sanity
check (FC11, on which the documents are automatically generated) has
dblatex nor docbook2x installed. I am not particularly enthused about
installing a lot of dependencies for these packages on my machine. I do
not want to bother k.org admins who are already overloaded to install
these on their machines either.
^ permalink raw reply
* Re: Issue 356 in msysgit: 'git describe --always' doesn't work
From: Junio C Hamano @ 2009-10-23 18:46 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <0016367b63e60b2cdb0476969d11@google.com>
msysgit@googlecode.com writes:
> Comment #1 on issue 356 by snaury: 'git describe --always' doesn't work
> http://code.google.com/p/msysgit/issues/detail?id=356
>
> This is not msysgit fault, the same happens on Mac OS X with
> 1.6.5.1. I guess --always doesn't work anymore...
Thanks for noticing. I think it is a regression in d68dc34 (git-describe:
Die early if there are no possible descriptions, 2009-08-06)
-- >8 --
Subject: [PATCH] Do not fail "describe --always" in a tag-less repository
This fixes a regression introduce by d68dc34 (git-describe: Die early if
there are no possible descriptions, 2009-08-06).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-describe.c | 2 +-
t/t6120-describe.sh | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index df67a73..7542b57 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -197,7 +197,7 @@ static void describe(const char *arg, int last_one)
for_each_ref(get_name, NULL);
}
- if (!found_names)
+ if (!found_names && !always)
die("cannot describe '%s'", sha1_to_hex(sha1));
n = cmit->util;
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 8c7e081..f5a1b61 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -34,6 +34,8 @@ test_expect_success setup '
echo one >file && git add file && git commit -m initial &&
one=$(git rev-parse HEAD) &&
+ git describe --always HEAD &&
+
test_tick &&
echo two >file && git add file && git commit -m second &&
two=$(git rev-parse HEAD) &&
^ permalink raw reply related
* Write and Submit Your First Kernel Patch
From: Kevyn-Alexandre Paré @ 2009-10-23 18:46 UTC (permalink / raw)
To: linux-newbie, kernel-janitors, git
Hi,
Just before I send my patch I got this error with:
./scripts/checkpatch.pl --terse --file
0001-Staging-comedi-driver-fix-coding-style.patch
0001-Staging-comedi-driver-fix-coding-style.patch:27: ERROR: trailing whitespace
0001-Staging-comedi-driver-fix-coding-style.patch:35: ERROR: trailing whitespace
0001-Staging-comedi-driver-fix-coding-style.patch:43: ERROR: trailing whitespace
0001-Staging-comedi-driver-fix-coding-style.patch:53: ERROR: trailing whitespace
I have done a step by step explanation of what I have done:
http://kapare.blogspot.com/2009/09/write-and-submit-your-first-kernel.html
It seem to me that the whitespace are added after I do this command:
git format-patch -s -n master..mybranch
Can someone help me with that because google did help me to found the answer?
Thx
kap
^ permalink raw reply
* Re: git bisect Vs branch
From: Junio C Hamano @ 2009-10-23 18:29 UTC (permalink / raw)
To: Grégory Romé; +Cc: git@vger.kernel.org
In-Reply-To: <4AE156A9.9060809@maxim-ic.com>
Grégory Romé <gregory.rome@maxim-ic.com> writes:
> Thanks Santi but I have a problem, due to the fact that the commit
> which has an impact on my code is in origin/master or
> first-origin/master
>
> When bisect checkout a commit from those branch I have none of my own
> modifications... So I can' test if my code is good or bad excepted if
> I can merge my commits in the bisect branch...
> ᐁ
> first-origin/master *---A---------B----------------o------C-
> \ \ \
> origin/master ----------B'----------U-----------C'-
> \ \ \
> master ------------U'----------C''-
>
>
> I generalized the problem but I can give a real example. My problem
> concerns an Linux USB driver for MIPS based SoC. first-origin is the
> official kernel repository and origin/master is the MIPS repository.
So the breakage is about the feature you added on your tree, which neither
of the grandparent upstream nor your direct upstream has. U' worked, C''^1
(i.e. immediately before you merged from your direct upstream at C'')
worked, and C'' doesn't.
This happens when a commit in the upstream (either in your direct upstream
or its upstream) changed the semantics of a function (or a variable's
value) in such a way that it invalidates some assumption that your code
has been relying on.
You can restate the problem into a slightly different form:
- If I merge C' to my master (C''^1), it breaks;
- If I merge U to my master (C''^1), it works;
- Starting from (U = good, C' = bad) pair, find the first "bad" commit,
where the badness is defined as "when it is merged to C''^1, it
breaks".
The restated problem is "where in their code did they change something
that breaks my code?"
You do not have to make a merge in the repository you are bisecting in.
For example, I would try something along this line:
$ git clone . ../test-build ;# make a build directory
$ M=$(git rev-parse master^1) ;# before the latest merge
$ U=$(git merge-base $M origin/master)
$ git bisect start
$ git bisect bad origin/master
$ git bisect good $U
This will check out one commit between U and C' (that will include commits
beetween B and C, as they are reachable from C' but not from U) for you to
test. Since the condition you are testing is "Does the result of merging
a commit to $M work?", you check exactly that condition:
$ H=$(git rev-parse HEAD)
$ cd ../test-build
$ git reset --hard
$ git checkout $M
$ git merge $H
... do your testing here ...
And go back to the repository you are bisecting, and tell the result to
bisect to continue:
$ cd -
$ git bisect good ;# or bad
And do the same for the next commit to be tested.
The result will tell you which commit in the upstream changed the
semantics of what you were relying on under you, and by examining that
change, hopefully you will know how to adjust your code to the new world
order the upstream (re-)defines.
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: Sverre Rabbelier @ 2009-10-23 18:27 UTC (permalink / raw)
To: gitzilla; +Cc: git, Shawn O. Pearce, Junio C Hamano, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <4AE0E542.8010501@gmail.com>
Heya,
On Thu, Oct 22, 2009 at 18:05, A Large Angry SCM <gitzilla@gmail.com> wrote:
> Your original email included 'make && make install'; it's the "make install"
> part I'm concerned about.
Ah, no, I meant that as part of my semi-regular git update (during
which I do 'make && make install') I want to have up-to-date bash
completion, preferably installed somewhere system-wide; currently I am
forced to have a 'source
/home/sverre/code/git/contrib/completion/git-completion.bash' in my
.bashrc,..
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox