gitfiletree metadata

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: gitfiletree metadata

Peter Uhnak


On Fri, Jul 24, 2015 at 10:47 AM, Peter Uhnák <[hidden email]> wrote:
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.

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?

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


Barely similar behavior to ghost changes is that when I finish my loading

script, DynaCASE package is marked as changed, but when I try to get diff
(changes) with (git)filetree, it says nothing has changed and this "changed"
mark disappears.

 When you look at the way the changed flag is set in Monticello, it is obvious false positives are the order of the day. So nothing really significant there ;) 

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. :)

Note to self: it may or may not be related to having github repository loaded for some unknown reason... because that shouldn't be there as I lock & load everything from local gitfiletree repos...
12