>
>
> Any comments?
>
> Edward
>
I think it would be useful to have some list of such changes in default
settings with the commits they were introduced and short description of the
reason why the change happened. When researching why some function of Leo
got broken, it should be the first thing to check. That's at least what I
have learned from dealing with this bug.
Well, as I write this I am realizing that it would be possible to just use
git blame on leoSettings.leo to see when some settings were
introduced/changed. Maybe we can formulate a procedure for hunting bugs
where this check could be one of the first steps.
...
I have just tried to see the blame of leoSettings.leo in browser on
github.com and it is too hard work for browser. I think that the @settings
tree should be kept in some external file under git control. That way blame
function of github.com would produce much smaller page.
I wasn't very familiar with git bisect functionality and it took me some
time to find my way through. At the end I think it is not overly
complicated. Should anyone else try to do it, here are some tips. First I
have cloned my Leo folder to /tmp/leo-trunk (* could be any temporary
folder). Then I made script (leo2) for launching Leo from that temporary
location. After that I ran ```git checkout c235ff4```. That was the second
last release (5.4.1). Then I ran leo2 and created a Leo file in
/tmp/bug.leo with one @clean node in it. Then I made script that changes
the content of the external @clean file. And I have tested that commit
c235ff4 doesn't contain bug. Then I have issued following command: ```git
bisect start``` and ```git bisect good```. After that ```git checkout
<latest commit>``` and then again ```leo2 /tmp/bug.leo```, followed by
executing the script to change @clean file. Leo didn't notice that file was
changed. That is why I issued ```git bisect bad```. After that git has
computed expected number of steps to find the problematic commit and
automatically checked out some commit in the middle. The following steps
were quite easy to perform:
1. leo2 /tmp/bug.leo #opens leo
2. run script to change @clean file
3. if Leo noticed that file was changed
3.1 git bisect good
if Leo didn't notice that file was changed
3.2 git bisect bad
4. close Leo
I kept repeating this four steps until git announced that the first commit
containing bug was ... I had 3 terminals open: one to start leo2, another
to start script for changing @clean file, and the third terminal was for
git commands.
English is not my primary language. Maybe someone can reformulate this in
concise and simple receipt, so that anyone who maybe contemplating to help
with git bisecting Leo's code-base in order to find source of some bug, has
clear and simple explanation of the process.
HTH Vitalije
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
