Hi,
on linux-next,
$ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
gives:
4a2d78822fdf
12ca45fea91c
09f2724a786f
These are patches from the year 2085, 2037 and 2030 respectively.
Would a checkpatch rule be helpful for these or are they too
isolated to waste runtime on?
Thanks!
Dwaipayan.
On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> Hi,
> on linux-next,
> $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> gives:
> 4a2d78822fdf
> 12ca45fea91c
> 09f2724a786f
>
> These are patches from the year 2085, 2037 and 2030 respectively.
>
> Would a checkpatch rule be helpful for these or are they too
> isolated to waste runtime on?
Dates come from your email client, not the patch itself, how is
checkpatch going to catch this?
thanks,
greg k-h
On Mon, Feb 1, 2021 at 5:37 PM Greg KH <[email protected]> wrote:
>
> On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > Hi,
> > on linux-next,
> > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > gives:
> > 4a2d78822fdf
> > 12ca45fea91c
> > 09f2724a786f
> >
> > These are patches from the year 2085, 2037 and 2030 respectively.
> >
> > Would a checkpatch rule be helpful for these or are they too
> > isolated to waste runtime on?
>
> Dates come from your email client, not the patch itself, how is
> checkpatch going to catch this?
>
Dwaipayan, there are two ways:
- We build a bot listening to mailing lists and check. I like that
implementation idea for various other checks.
- Stephen Rothwell could include this as a check on linux-next and
inform the git author and committer.
I am wondering though if that is worth the effort, three instances of
a wrong date among 1M commits seems to be very seldom and the harm of
that mistake is quite small as well.
Lukas
On Mon, Feb 1, 2021 at 10:07 PM Greg KH <[email protected]> wrote:
>
> On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > Hi,
> > on linux-next,
> > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > gives:
> > 4a2d78822fdf
> > 12ca45fea91c
> > 09f2724a786f
> >
> > These are patches from the year 2085, 2037 and 2030 respectively.
> >
> > Would a checkpatch rule be helpful for these or are they too
> > isolated to waste runtime on?
>
> Dates come from your email client, not the patch itself, how is
> checkpatch going to catch this?
>
I was hoping that the maintainer could catch it before merging it
into his tree. Dates being a trivial thing might slip human eyes,
but checkpatch might detect it there.
Thanks,
Dwaipayan.
On Mon, Feb 1, 2021 at 10:20 PM Lukas Bulwahn <[email protected]> wrote:
>
> On Mon, Feb 1, 2021 at 5:37 PM Greg KH <[email protected]> wrote:
> >
> > On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > > Hi,
> > > on linux-next,
> > > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > > gives:
> > > 4a2d78822fdf
> > > 12ca45fea91c
> > > 09f2724a786f
> > >
> > > These are patches from the year 2085, 2037 and 2030 respectively.
> > >
> > > Would a checkpatch rule be helpful for these or are they too
> > > isolated to waste runtime on?
> >
> > Dates come from your email client, not the patch itself, how is
> > checkpatch going to catch this?
> >
>
> Dwaipayan, there are two ways:
> - We build a bot listening to mailing lists and check. I like that
> implementation idea for various other checks.
> - Stephen Rothwell could include this as a check on linux-next and
> inform the git author and committer.
>
> I am wondering though if that is worth the effort, three instances of
> a wrong date among 1M commits seems to be very seldom and the harm of
> that mistake is quite small as well.
>
I agree. I felt it was isolated as well but it might affect people who do
static analysis on the commits or such.
The idea of a bot seems nice though in general.
People do have all the style checking scripts at their disposal, but still
we see style issues on the list.
Something similar to the kernel test robot, but for style issues seems nice.
Is it something the community would like?
Thanks,
Dwaipayan.
On Mon, Feb 01, 2021 at 05:50:45PM +0100, Lukas Bulwahn wrote:
>
> Dwaipayan, there are two ways:
> - We build a bot listening to mailing lists and check. I like that
> implementation idea for various other checks.
> - Stephen Rothwell could include this as a check on linux-next and
> inform the git author and committer.
>
> I am wondering though if that is worth the effort, three instances of
> a wrong date among 1M commits seems to be very seldom and the harm of
> that mistake is quite small as well.
Another solution might be to ask the git developers if they would be
willing to have "git am" print a warning if the date is sufficiently
insane (say, more than 3 months in the past or present).
One could also imagine a request that "git log" would have a new
format where normally the author time is printed, but if it's
sufficiently different from the commit time, the commit time is also
printed in parenthesis.
Or you could set up your git config so that "git log" uses
--pretty=fuller by default, which prints both the author date and
commit date.
Like Lukas, I'm not really sure it's worth the effort, however.
- Ted
On Mon, Feb 01, 2021 at 10:31:33PM +0530, Dwaipayan Ray wrote:
> On Mon, Feb 1, 2021 at 10:07 PM Greg KH <[email protected]> wrote:
> >
> > On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > > Hi,
> > > on linux-next,
> > > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > > gives:
> > > 4a2d78822fdf
> > > 12ca45fea91c
> > > 09f2724a786f
> > >
> > > These are patches from the year 2085, 2037 and 2030 respectively.
> > >
> > > Would a checkpatch rule be helpful for these or are they too
> > > isolated to waste runtime on?
> >
> > Dates come from your email client, not the patch itself, how is
> > checkpatch going to catch this?
> >
>
> I was hoping that the maintainer could catch it before merging it
> into his tree. Dates being a trivial thing might slip human eyes,
> but checkpatch might detect it there.
What is the problem here. You can't treat dates that patches were
"created", you have to always go off of the release the patches showed
up in. So while you might want to do a sliding scale of 4 months or so,
in reality we have patches committed to the tree today that were written
years ago.
I think I still hold the record for "time it took to get a patch merged"
with a very old devfs removal patch, which was many many years...
thanks,
greg k-h
On Mon, 2021-02-01 at 22:41 +0530, Dwaipayan Ray wrote:
> The idea of a bot seems nice though in general.
> People do have all the style checking scripts at their disposal, but still
> we see style issues on the list.
>
> Something similar to the kernel test robot, but for style issues seems nice.
> Is it something the community would like?
(Adding lkp)
Maybe yes, but likely it depends on the particular audience so
no, not really.
The kbuild test robot used to run checkpatch on patches and there
there was negative feedback. I don't know if the robot is still
running checkpatch with some subset of message types.
A thread from 2013:
https://lore.kernel.org/lkml/20130903003958.GA6855@localhost/
On Tue, Feb 02, 2021 at 04:48:04AM -0800, Joe Perches wrote:
> On Mon, 2021-02-01 at 22:41 +0530, Dwaipayan Ray wrote:
> > The idea of a bot seems nice though in general.
> > People do have all the style checking scripts at their disposal, but still
> > we see style issues on the list.
> >
> > Something similar to the kernel test robot, but for style issues seems nice.
> > Is it something the community would like?
>
> (Adding lkp)
>
> Maybe yes, but likely it depends on the particular audience so
> no, not really.
>
> The kbuild test robot used to run checkpatch on patches and there
> there was negative feedback. I don't know if the robot is still
> running checkpatch with some subset of message types.
Hi Joe, we had disabled the checkpatch due to low fruit with very limited
useful reports. Is there any recommendation like which kind of types can
be interested?
Thanks
>
> A thread from 2013:
>
> https://lore.kernel.org/lkml/20130903003958.GA6855@localhost/
>
>