On Tue, Oct 18, 2016 at 8:58 AM, 'Terry Brown' via leo-editor <
> No. Commit hooks are always for systems with git.
> What I meant was that it would be confusing to sometimes report, at the
> top of the log pane, the preceding commit hash, and sometimes report the
> current commit hash depending on whether .git was available.
I now see that this is primarily a "fit and finish" issue. Leo's signon
should follow accepted practice by giving build info, including date and
So I'm now convinced that git hooks should stay. We can debate how often
signon info helps devs fix bugs, but that's a secondary consideration.
Technical point, my recollection when the system was first developed
> was that best practice was to use bash for hooks. Of course anyone
> developing Leo has Python on their system somewhere, but not
> necessarily on the path, whereas git, even on Windows, executes hooks
> in bash.
The hook can add to sys.path as needed--it's running from a known place,
More importantly, the hook should generate a .json file compatible with
those created and read by leoVersion.py. Calling
leoVersion.create_commit_timestamp_json is the proper way to do this.
I'm going to create the new hooks next, before b1 goes out the door.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.