Re: [PATCH] git-am: flag suspiciously old or futuristic commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 29, 2015 at 3:01 PM, Paul Gortmaker
<paul.gortmaker@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
> ---
>  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)

> +
> +               if [ "$GIT_AUTHOR_YEAR" -le "$TOO_OLD" ]; then
> +                       say "$(gettext "note: commit is from implausibly old year $GIT_AUTHOR_YEAR.")"
> +               fi
> +               if [ "$GIT_AUTHOR_YEAR" -ge "$TOO_NEW" ]; then
> +                       say "$(gettext "note: commit is from future year $GIT_AUTHOR_YEAR.")"
> +               fi
> +       fi
> +
>         export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
>
>         case "$resume" in
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]