From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Jacob Keller <jacob.keller@gmail.com>,
Stefan Beller <sbeller@google.com>
Cc: Paul Tan <pyokagan@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] git-am: flag suspiciously old or futuristic commits
Date: Thu, 30 Jul 2015 11:07:37 -0400 [thread overview]
Message-ID: <55BA3DB9.7020700@windriver.com> (raw)
In-Reply-To: <CA+P7+xqcWKVnyL-+chiBLJn2TBJwPuy4WG2H1yS_hCN2cx=KNw@mail.gmail.com>
On 2015-07-30 12:35 AM, Jacob Keller wrote:
> On Wed, Jul 29, 2015 at 3:20 PM, Stefan Beller <sbeller@google.com> wrote:
>> On Wed, Jul 29, 2015 at 3:01 PM, Paul Gortmaker
>> <paul.gortmaker@windriver.com> wrote:
>>> The linux kernel repository has some commits in it with dates from
>>> the year 1970 and also 2030 (and possibly others). We probably shouldi
>>> warn people when the dates look suspect.
>>>
>>> For commits in the future, note that a committer in Australia
>>> could commit on New Years Day, and send it to a maintainer in North
>>> America and that would trip the notification on the maintainer's
>>> New Years Eve. But that is unlikely, and the note is still
>>> correct; that the commit is from a future year.
>>>
>>> For commits in the past, I chose a somewhat arbitrary 30 year
>>> limit, which will allow stuff from post 1985; the thought being
>>> that someone might want to import an old repo into git from some
>>> other SCM. We could alternatively set it to 5, which would then
>>> catch computers with a dead CMOS battery, at the risk of pestering
>>> the hypothetical museum curator of old bits.
>>>
>>> Sample output:
>>>
>>> paul@builder:~/git/linux-head$ grep Date: *patch
>>> future.patch:Date: Sat, 18 Jul 2037 21:22:19 -0400
>>> past.patch:Date: Sat, 18 Jul 1977 21:22:19 -0400
>>>
>>> paul@builder:~/git/linux-head$ git am future.patch
>>> note: commit is from future year 2037.
>>> Applying: arch/sh: make heartbeat driver explicitly non-modular
>>> paul@builder:~/git/linux-head$ git reset --hard HEAD~ > /dev/null
>>> paul@builder:~/git/linux-head$ git am past.patch
>>> note: commit is from implausibly old year 1977.
>>> Applying: arch/sh: make heartbeat driver explicitly non-modular
>>> paul@builder:~/git/linux-head$
>>>
>>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>> ---
>>> git-am.sh | 15 +++++++++++++++
>>> 1 file changed, 15 insertions(+)
>>>
>>> diff --git a/git-am.sh b/git-am.sh
>>
>> [+cc paul tan, who rewrote am in c as a GSoC project.]
>>
>>> index 3af351ffaaf3..ff6deb8047a4 100755
>>> --- a/git-am.sh
>>> +++ b/git-am.sh
>>> @@ -766,6 +766,21 @@ To restore the original branch and stop patching run \"\$cmdline --abort\"."
>>> stop_here $this
>>> fi
>>>
>>> + if test -n "$GIT_AUTHOR_DATE"
>>> + then
>>> + THIS_YEAR=`date +%Y`
>>> + TOO_OLD=$(expr $THIS_YEAR - 30)
>>> + TOO_NEW=$(expr $THIS_YEAR + 1)
>>> + GIT_AUTHOR_YEAR=`date -d "$GIT_AUTHOR_DATE" +%Y`
>>
>> Would it make sense to not operate on year but on unix time, so the problem
>> you mentioned in the commit message goes away?
>>
>> Another thought:
>> Having this check in am seems a bit arbitrary to me (or rather
>> workflow adapted ;) as
>> we could also check in commit or pull (not sure if I actually mean the
>> fetch or merge thereof)
>>
>
> I think this makes most sense in am, as it is most likely to show up,
> in my mind, due to a format-patch mistake. If we do it during pull,
> would we just warn? how would we reject commits? that doesn't really
> fit..
So, it turns out this breaks t3400-rebase test since I was not aware
of the git internal date format (which that test suite uses).
And on top of that, in talking with a *BSD user, it seems the "-d"
flag isn't universal. Over in that camp it means set DST offset. :(
So while I think the idea is sound, and worthwhile, scripting it will
become a lot more cumbersome and klunky. If git-am becomes C, then
it would be easier to handle there, I think....
Paul.
--
>
> We can't do it during commit, as obviously the broken machine will
> likely not be able to notice it at all.. We could check remotes during
> push but that doesn't solve this either..
>
> Maybe just emitting a warning during a fetch or am (since am doesn't
> use pull) would make the most sense?
>
> I don't think we can reject things when doing a fetch though, but we could warn.
>
> Regards,
> Jake
>
prev parent reply other threads:[~2015-07-30 15:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 22:01 [PATCH] git-am: flag suspiciously old or futuristic commits Paul Gortmaker
2015-07-29 22:20 ` Stefan Beller
2015-07-30 4:35 ` Jacob Keller
2015-07-30 15:07 ` Paul Gortmaker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55BA3DB9.7020700@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=git@vger.kernel.org \
--cc=jacob.keller@gmail.com \
--cc=pyokagan@gmail.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.