Hi Peter, 2015-07-24 10:47 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
Check which versions are bold when you open the package. Because when I
use gitfiletree it usually shows me that the latest few versions are not loaded (they are in bold) but I am anyway on the latest one.
As I've said, it shows me that I am on the latest version.
I'm looking at DynaCASE-PeterUhnak.147, the one with the interesting history...
Maybe this happens to you because you load it from github and only after you add gitfiletree? (At least from what I remember what you've shown me (and you are using GitFileTree from MetaRepo30?))
Understood. So this means all commits you've done (the -bliznjan) were
done with filetree?
He suffered through with git on Windows for some time, so maybe the later half?
Again, sorry for that poor Windows support... GitFileTree is an excellent bench for the robustness of the external process support, and I only barely touch the underlying plugin on Unix-like platform. I'll write for professional reasons another possibility for support on Windows, but it won't be available.
Sorry for the lack of support on windows. You'll have to wait for
libcgit.
Is there an estimated timeline when this will be? (weeks, months, years, ...?)
I don't know; the lib has been included in the Pharo vm for a long time, and I remember talks about having it for Pharo5. Stef, what is the Pharo consortium plans on that?
Yes, this also happens to me, but it is different. Actually this is what I was expecting would happen in the issue described originally... that when I check changes (and it was already committed) that it would just disappear as false positive... but nope, it still claimed it's new and only actual git history have shown that it was a false positive.
Anyway, it doesn't seem there will be resolution for this until it can be reproduced consistently... so I'll try be more observant. :)
Well, it may be an issue in the way diffs are built, so it would be good to see it confirmed. Thanks for volunteering, by the way :) Thierry