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

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 

*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 


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 

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.


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.

Reply via email to