On Tue, 18 Oct 2016 04:33:08 -0700 (PDT)
"Edward K. Ream" <edream...@gmail.com> wrote:
> On Monday, October 17, 2016 at 11:12:09 AM UTC-5, Edward K. Ream
> wrote:
>
> These are the commit-msg and pre-commit files in
> leo-editor/.git/hooks.
> >
> > They won't do any harm, or even be all that inconvenient, but they
> > serve no purpose now.
> >
>
> When I awoke this morning, I knew I should push back against the
> notion that the present git hooks are useful. They are not.
>
> *Executive summary*
>
> The format of commit_timestamp.json (let's just call it the .json
> file) created by the hooks contain only time/date information,
> encoded in two different ways. *It doesn't have a hash key.* Couldn't
> we stop right here? How can the .json file be useful without any hash
> data??
Because what we want is a unique commit ID. That doesn't have to be
the commit's hash.
The goal is to uniquely identify a commit, to minimize confusion when
cooperating with bug reporters to fix bugs.
I don't think anyone disagrees with the best place for this unique ID
being the top of the log output.
If we know the timestamp, 201501234567, we know the the commit, done.
If you use the hash, you need to know if it's a hash for a system with or
without .git, because in one case it's a preceding hash, and in the other
it's the current hash.
Also, every time there's a merge, the preceding hash has no unique
following commit.
Forgetting to install hooks can be addressed by monitoring, I can do
that if it's deemed necessary.
But if we never use them, they're not needed - seems like a reasonable
argument. So let's check:
In my Leo mail folder:
grep -ril 'build.*20[0-9]\{6\}' * | xargs grep -iL 'Git repo info' | xargs grep
-iL '^From:.*Edward' | wc -l
this counts msgs. that have the word 'build' followed by a timestamp
(on the same line), excluding messages that also contain 'Git repo
info', suggesting the user pasted in log info. from a system with .git
present, and messages from Edward, to avoid not only the messages in
which Edward heartily endorsed the timestamp system ;-) but also
messages where he pasted the commit message containing
'build.*20[0-9]\{6\}', something he does more than most, and they
shouldn't be counted.
121 message since August 2014. Let's say 110 after dropping the
initial discussion about the timestamp IDs, and call 50% false
positives, so 55 messages in two years, a couple a month.
To me that's high enough utilization to keep the only robust,
unambiguous method we have for identifying specific commits.
Cheers -Terry
> The rest of this long post is an Engineering Notebook entry. Feel
> free to ignore, unless you are a Leo dev.
>
> *The old code*
>
> The present git hooks are bash scripts. They write the system date
> two different ways. As this page
> <http://tech.myemma.com/python-pep8-git-hooks/?gclid=CKzCmrKO5M8CFQuLaQod5AIK6A>
>
> shows, it is possible to write git hooks in python. In that case,
> the hook could write the hash of the *previous* commit, the one just
> *before* the commit that is about to happen.
>
> *The new code*
>
> The signon code contains this line:
>
> commit, date = leoVersion.commit, leoVersion.date
>
> When git is not available, commit is empty and date comes from
> the .json file.
>
> When git *is* available gets these data using "git log -1" to access
> the previous commit, the last commit that *has* *already *happened.
>
> The make-leo script calls calls create_commit_timestamp_json() in
> leoVersion.py to write a copy of the .json file that *does* contain a
> hash key. This will refer to the last commit, *provided* the script
> is run when there are no unchanged files. In practice, this is the
> case. The distribution checklist in leoDist.leo should mention this
> constraint.
>
> *Daily builds*
>
> There is no hash data *whatsoever* available when downloading using
> the latest
> <https://github.com/leo-editor/leo-editor/archive/master.zip>link on
> Leo's download page <http://leoeditor.com/download.html>. Other
> download links do provide "funky" hash data in the .zip file's
> filename, but apparently users never notice this data. The discussion
> of daily downloads has been a red herring.
>
> *Fixing bugs*
>
> In this post
> <https://groups.google.com/d/msg/leo-editor/o1fKiy-rymA/iOiHxqo6BQAJ>,
> Jake says: "I'm with Terry on this -- the commit_timestamp.json file
> has been immensely helpful in debugging user issues in the past.
> Relegating the commit hash to some funky filename is not an
> acceptable option."
>
> This can't be correct--the .json file contains no hash key.
>
> And the date seems not to have been useful either. I forgot to
> install the git hooks, and nobody else committed anything for awhile,
> so the build date was stuck in July for several months without anyone
> ever noticing!
>
> In short, the .json file seems never to have been useful in solving
> bugs, or even identifying Leo builds.
>
> Once in a great while Terry and I have used git bisect to track down
> a worthy bug. But we *are* running in a git environment. In that
> case, the .json file is certainly useless.
>
> Why haven't we devs noticed how useless the .json data is? Probably
> because we all work in a git environment in which the .json file is
> irrelevant.
>
> *Summary*
>
> 1. The git hooks create a .json file that contains no hash key.
> Apparently nobody has ever used hash data from daily downloads. Those
> who think otherwise (including me yesterday) are simply mistaken.
>
> 2. We devs haven't noticed how useless the .json is because we work
> in git environments.
>
> I can't force anyone to remove the git hooks. Otoh, you can't force
> me to use them ;-) The present code works *regardless *of whether
> other devs use git hooks.
>
> Edward
>
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
