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?? 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.
