Hi, it seems that I managed to completely fuck up my gitfiletree metadata... e.g.: Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91 I am also starting to see a lot of ghost changes etc. Now, someone mentioned that it would be possible to delete all the .version and methodProperties.json and whatnot and generate it directly from git. So my question is, is this possible? If yes, how? If no, what would need to be done (implemented) to make it so? Or at least is it possible to completely regenerate all the metadata purely from git? (To clean up all the mess until.) Peter
Hi Peter, no, I don't think you fucked up your gitfiletree metadata. But the explanation is a bit complex. First thing is that you are looking at a git generated metadata... So what you're asking for (regenerating from git) is already what you are looking at :) Second is that gitfiletree walks your git log to rebuilt the version history. So, I guess that if you look at your git with something like gitg, you will recognize all the versions coming along the diagram lines. It is linked a bit in the way gitfiletree reads through the merges in the git history. I was surprised by that effect, I had a look and yes, there is a good reason for having this done in that way, even if it is a bit surprising at first. Don't remember the exact reasoning... but it was linked to the way git links commits to directories and how merge points appear. If you want to explore that part of GitFileTree, it is in GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:. The ghost changes are something else, however. Can you elaborate? Thierry Le 23/07/2015 23:49, Peter Uhnák a écrit :
Hi,
it seems that I managed to completely fuck up my gitfiletree metadata...
e.g.: Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91
I am also starting to see a lot of ghost changes etc.
Now, someone mentioned that it would be possible to delete all the .version and methodProperties.json and whatnot and generate it directly from git.
So my question is, is this possible? If yes, how? If no, what would need to be done (implemented) to make it so?
Or at least is it possible to completely regenerate all the metadata purely from git? (To clean up all the mess until.)
Peter
On Fri, Jul 24, 2015 at 12:26 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
Hi Peter,
no, I don't think you fucked up your gitfiletree metadata. But the explanation is a bit complex.
First thing is that you are looking at a git generated metadata... So what you're asking for (regenerating from git) is already what you are looking at :)
Second is that gitfiletree walks your git log to rebuilt the version history. So, I guess that if you look at your git with something like gitg, you will recognize all the versions coming along the diagram lines.
It is linked a bit in the way gitfiletree reads through the merges in the git history. I was surprised by that effect, I had a look and yes, there is a good reason for having this done in that way, even if it is a bit surprising at first. Don't remember the exact reasoning... but it was linked to the way git links commits to directories and how merge points appear.
If you want to explore that part of GitFileTree, it is in GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:.
Hmm, I'll look at that but still I think it shows way more than it should.
The ghost changes are something else, however. Can you elaborate?
Basically Pharo (Monticello Browser/Nautilus) shows that a package has changes... so I look at the changes (to see what I'm committing) and I see things that I've already committed. And if I commit it again, only metadata will change (because it was already committed), but the dirty flag will disappear. I have no idea under what circumstances this happens, I thought that maybe I am in different commit... but monticello browser says that I am at the latest one... So I have yet to tell what is the cause. Peter
Thierry
Le 23/07/2015 23:49, Peter Uhnák a écrit :
Hi,
it seems that I managed to completely fuck up my gitfiletree metadata...
e.g.: Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91
I am also starting to see a lot of ghost changes etc.
Now, someone mentioned that it would be possible to delete all the .version and methodProperties.json and whatnot and generate it directly from git.
So my question is, is this possible? If yes, how? If no, what would need to be done (implemented) to make it so?
Or at least is it possible to completely regenerate all the metadata purely from git? (To clean up all the mess until.)
Peter
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. Uko
On 24 Jul 2015, at 02:29, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Fri, Jul 24, 2015 at 12:26 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote: Hi Peter,
no, I don't think you fucked up your gitfiletree metadata. But the explanation is a bit complex.
First thing is that you are looking at a git generated metadata... So what you're asking for (regenerating from git) is already what you are looking at :)
Second is that gitfiletree walks your git log to rebuilt the version history. So, I guess that if you look at your git with something like gitg, you will recognize all the versions coming along the diagram lines.
It is linked a bit in the way gitfiletree reads through the merges in the git history. I was surprised by that effect, I had a look and yes, there is a good reason for having this done in that way, even if it is a bit surprising at first. Don't remember the exact reasoning... but it was linked to the way git links commits to directories and how merge points appear.
If you want to explore that part of GitFileTree, it is in GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:.
Hmm, I'll look at that but still I think it shows way more than it should.
The ghost changes are something else, however. Can you elaborate?
Basically Pharo (Monticello Browser/Nautilus) shows that a package has changes... so I look at the changes (to see what I'm committing) and I see things that I've already committed. And if I commit it again, only metadata will change (because it was already committed), but the dirty flag will disappear.
I have no idea under what circumstances this happens, I thought that maybe I am in different commit... but monticello browser says that I am at the latest one... So I have yet to tell what is the cause.
Peter
Thierry
Le 23/07/2015 23:49, Peter Uhnák a écrit : Hi,
it seems that I managed to completely fuck up my gitfiletree metadata...
e.g.: Ancestors: DynaCASE-PeterUhnak.148, DynaCASE-PeterUhnak.93, DynaCASE-PeterUhnak.144, DynaCASE-PeterUhnak.146, DynaCASE-PeterUhnak.92, DynaCASE-PeterUhnak.142, DynaCASE-PeterUhnak.140, DynaCASE-PeterUhnak.138, DynaCASE-PeterUhnak.139, DynaCASE-bliznjan.127, DynaCASE-PeterUhnak.137, DynaCASE-PeterUhnak.125, DynaCASE-PeterUhnak.126, DynaCASE-bliznjan.123, DynaCASE-bliznjan.121, DynaCASE-bliznjan.120, DynaCASE-PeterUhnak.119, DynaCASE-PeterUhnak.117, DynaCASE-PeterUhnak.115, DynaCASE-bliznjan.113, DynaCASE-PeterUhnak.111, DynaCASE-PeterUhnak.110, DynaCASE-PeterUhnak.108, DynaCASE-PeterUhnak.102, DynaCASE-bliznjan.95, DynaCASE-bliznjan.98, DynaCASE-PeterUhnak.91
I am also starting to see a lot of ghost changes etc.
Now, someone mentioned that it would be possible to delete all the .version and methodProperties.json and whatnot and generate it directly from git.
So my question is, is this possible? If yes, how? If no, what would need to be done (implemented) to make it so?
Or at least is it possible to completely regenerate all the metadata purely from git? (To clean up all the mess until.)
Peter
Peter, is this the dynacase at https://github.com/dynacase/dynacase ? Thierry Le 24/07/2015 02:29, Peter Uhnák a écrit :
On Fri, Jul 24, 2015 at 12:26 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Hi Peter,
no, I don't think you fucked up your gitfiletree metadata. But the explanation is a bit complex.
First thing is that you are looking at a git generated metadata... So what you're asking for (regenerating from git) is already what you are looking at :)
Second is that gitfiletree walks your git log to rebuilt the version history. So, I guess that if you look at your git with something like gitg, you will recognize all the versions coming along the diagram lines.
It is linked a bit in the way gitfiletree reads through the merges in the git history. I was surprised by that effect, I had a look and yes, there is a good reason for having this done in that way, even if it is a bit surprising at first. Don't remember the exact reasoning... but it was linked to the way git links commits to directories and how merge points appear.
If you want to explore that part of GitFileTree, it is in GitFileTreePackageEntry>>buildInfoWith:startingAt:version:ancestry:.
Hmm, I'll look at that but still I think it shows way more than it should.
The ghost changes are something else, however. Can you elaborate?
Basically Pharo (Monticello Browser/Nautilus) shows that a package has changes... so I look at the changes (to see what I'm committing) and I see things that I've already committed. And if I commit it again, only metadata will change (because it was already committed), but the dirty flag will disappear.
I have no idea under what circumstances this happens, I thought that maybe I am in different commit... but monticello browser says that I am at the latest one... So I have yet to tell what is the cause.
Peter
Yes it is. I personally never ran into such ghost changes when I was using gitfiletree. This might be also useful information: We are two contributors and Peter uses GitFileTree but I use FileTree because GitFileTree crashes all the time on Win 7 ( http://forum.world.st/Gitfiletree-unstable-on-Windows-td4816354.html ). 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. Jan Thierry Goubier wrote
Peter, is this the dynacase at https://github.com/dynacase/dynacase ?
Thierry
-- View this message in context: http://forum.world.st/gitfiletree-metadata-tp4838970p4839019.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
2015-07-24 9:21 GMT+02:00 Jan BlizniÄenko <bliznjan@fit.cvut.cz>:
Yes it is.
I personally never ran into such ghost changes when I was using gitfiletree. This might be also useful information: We are two contributors and Peter uses GitFileTree but I use FileTree because GitFileTree crashes all the time on Win 7 ( http://forum.world.st/Gitfiletree-unstable-on-Windows-td4816354.html ).
Understood. So this means all commits you've done (the -bliznjan) were done with filetree? Sorry for the lack of support on windows. You'll have to wait for libcgit.
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 ;) Thierry
Jan
Thierry Goubier wrote
Peter, is this the dynacase at https://github.com/dynacase/dynacase ?
Thierry
-- View this message in context: http://forum.world.st/gitfiletree-metadata-tp4838970p4839019.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.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. 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. :) Thanks, Peter
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
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?
CCed Stef :) ^^
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 :)
As I'm the only one experiencing this apparently, I don't have a choice but to volunteer. :)
Hi Peter, here is my analysis on DynaCASE-PeterUhnak.147. When going through the history on git, many of the merges do not register as belonging to the DynaCASE package (a git commit belongs to a package when it modify something inside the package directory or modify the version file, I don't remember which indicator I used...). So, to be able to recover all the parents of DynaCASE-PeterUhnak.147, the algorithm (one) has to go through thoses merges transitively until all the branches it has so followed ends with a commit belonging to DynaCASE. Sometimes, drawing this as a graph in the repository inspector would help immensely... Alex, would you be able to show something with Roassal? It would be really nice to see the overall git history graph overlaid with the graph of the history of the selected package. By the way, if you want to explore some of the issues you have to tackle when reading metadata in a git repository, I suggest trying gitg on the dynacase repository... and wait :) Makes Pharo look like a speedy beast :) Thierry 2015-07-24 11:05 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
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?
CCed Stef :) ^^
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 :)
As I'm the only one experiencing this apparently, I don't have a choice but to volunteer. :)
Alex, would you be able to show something with Roassal? It would be really nice to see the overall git history graph overlaid with the graph of the history of the selected package.
Interesting that if someone else needs it I have no problem writing Roassal scripts etc, but when I need it I don't even think of using Roassal to actually solve my problems... Anyway I ran into similar issue I had before, that McFileTreeGitRepository is returning GitFileTreePackageEntry instead of filenames, so this fails. ~~~~~~~~~~~~~~~~ mc := MCFileTreeGitRepository allInstances detect: [ :m | m name includesSubstring: 'dynacase/repository' ]. root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc readableFileNames doesn't return file names" ~~~~~~~~~~~~~~~ (The above for SmalltalkHub repos works just fine.) This is the previous issue you've already fixed http://forum.world.st/GitFileTree-browsing-changes-doesn-t-work-in-Pharo-5-t... , it seems related. Peter
2015-07-24 13:04 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
Alex, would you be able to show something with Roassal? It would be really
nice to see the overall git history graph overlaid with the graph of the history of the selected package.
Interesting that if someone else needs it I have no problem writing Roassal scripts etc, but when I need it I don't even think of using Roassal to actually solve my problems...
:)
Anyway I ran into similar issue I had before, that McFileTreeGitRepository is returning GitFileTreePackageEntry instead of filenames, so this fails.
~~~~~~~~~~~~~~~~ mc := MCFileTreeGitRepository allInstances detect: [ :m | m name includesSubstring: 'dynacase/repository' ].
root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc readableFileNames doesn't return file names" ~~~~~~~~~~~~~~~ (The above for SmalltalkHub repos works just fine.)
Yes. I spent a lot of time try to guess what was the repository API used by Monticello, and I failed for part of it ;) With git, I couldn't work with something as primitive as a file name to refer to a git commit :) so had to work at a higher level and try to patch all the places where Monticello was forcing strings on me.
This is the previous issue you've already fixed http://forum.world.st/GitFileTree-browsing-changes-doesn-t-work-in-Pharo-5-t... , it seems related.
Ok. It is present in Pharo 4 as well, then. Thanks, Thierry
On Fri, Jul 24, 2015 at 1:13 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-07-24 13:04 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
Alex, would you be able to show something with Roassal? It would be
really nice to see the overall git history graph overlaid with the graph of the history of the selected package.
Interesting that if someone else needs it I have no problem writing Roassal scripts etc, but when I need it I don't even think of using Roassal to actually solve my problems...
:)
Anyway I ran into similar issue I had before, that McFileTreeGitRepository is returning GitFileTreePackageEntry instead of filenames, so this fails.
~~~~~~~~~~~~~~~~ mc := MCFileTreeGitRepository allInstances detect: [ :m | m name includesSubstring: 'dynacase/repository' ].
root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc readableFileNames doesn't return file names" ~~~~~~~~~~~~~~~ (The above for SmalltalkHub repos works just fine.)
Yes. I spent a lot of time try to guess what was the repository API used by Monticello, and I failed for part of it ;)
With git, I couldn't work with something as primitive as a file name to refer to a git commit :) so had to work at a higher level and try to patch all the places where Monticello was forcing strings on me.
Ok, so should I work around this because it's unfixable, or is it a bug?
This is the previous issue you've already fixed http://forum.world.st/GitFileTree-browsing-changes-doesn-t-work-in-Pharo-5-t... , it seems related.
Ok. It is present in Pharo 4 as well, then.
I'm not sure how is Pharo 4 related (I do all dev in 5 now).
Thanks,
Thierry
On Fri, Jul 24, 2015 at 1:24 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-07-24 13:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
I'm not sure how is Pharo 4 related (I do all dev in 5 now).
I should update DynaCASE docs, if that's where you got that impression...
Yes, from the DynaCASE doc, I believed you were in Pharo4 :)
Sorry, I've fixed that now. I moved to Pharo 5 during ESUG and forgot to update it. In fact the original issue emerged after I switched to 5, so in 4 it should be ok. Peter
Le 24/07/2015 13:26, Peter Uhnák a écrit :
On Fri, Jul 24, 2015 at 1:24 PM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-07-24 13:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
I'm not sure how is Pharo 4 related (I do all dev in 5 now).
I should update DynaCASE docs, if that's where you got that impression...
Yes, from the DynaCASE doc, I believed you were in Pharo4 :)
Sorry, I've fixed that now. I moved to Pharo 5 during ESUG and forgot to update it. In fact the original issue emerged after I switched to 5, so in 4 it should be ok.
Ok, regarding the error, I'm correcting it as I write this email and... The semantics of Monticello (or the changes done in Pharo5 because I never saw them before) are horrible. There is for example, code encapsulated with <<on: Error do:>> which totally get the wrong result (and hide the error) when ordering versions in a repository. In short, I suspect your problem with changes are linked to that. Man, how I hate having to cope with code like that. Thierry
Peter
2015-07-24 13:18 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
On Fri, Jul 24, 2015 at 1:13 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2015-07-24 13:04 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
Alex, would you be able to show something with Roassal? It would be
really nice to see the overall git history graph overlaid with the graph of the history of the selected package.
Interesting that if someone else needs it I have no problem writing Roassal scripts etc, but when I need it I don't even think of using Roassal to actually solve my problems...
:)
Anyway I ran into similar issue I had before, that McFileTreeGitRepository is returning GitFileTreePackageEntry instead of filenames, so this fails.
~~~~~~~~~~~~~~~~ mc := MCFileTreeGitRepository allInstances detect: [ :m | m name includesSubstring: 'dynacase/repository' ].
root := mc versionInfoFromFileNamed: mc readableFileNames first. "<-- mc readableFileNames doesn't return file names" ~~~~~~~~~~~~~~~ (The above for SmalltalkHub repos works just fine.)
Yes. I spent a lot of time try to guess what was the repository API used by Monticello, and I failed for part of it ;)
With git, I couldn't work with something as primitive as a file name to refer to a git commit :) so had to work at a higher level and try to patch all the places where Monticello was forcing strings on me.
Ok, so should I work around this because it's unfixable, or is it a bug?
No, it's a bug... But one of a whack-a-mole type :). FileTree (and GitFileTree) have a bunch of tests for internal coverage (reading, writing, etc....) with a complex setup (you need to provide test repositories)... which isn't included in Pharo integration testing by the way. However there are weaknesses in the Gofer to repositories testing (again probably because setting up a test environment with test repositories for Pharo would be complex). Thierry
Hi Peter, On Fri, Jul 24, 2015 at 1:04 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
Alex, would you be able to show something with Roassal? It would be really
nice to see the overall git history graph overlaid with the graph of the history of the selected package.
Interesting that if someone else needs it I have no problem writing Roassal scripts etc, but when I need it I don't even think of using Roassal to actually solve my problems...
You nailed an important point here. In humane assessment I distinguish between two roles: stakeholder and facilitator. Theoretically, these can both be fulfilled by the same person at the same time, but this often proves to be strangely difficult. I noticed this issue when I fixed a rather funny Glamour bug that haunted us for more than 6 months, until I finally figured it out by building a visualization that took 1h of effort: http://www.humane-assessment.com/blog/chasing-rogue-announcements/ Reasoning about software systems is more tricky than we think. I believe there are two dimensions at play: - Getting tools to be cheaply moldable is one. This is where the history we have with Moose/Roassal/GT et co can play an important role. And we should certainly not stop at what exists. For example, your work on live visual manipulation is an important direction. So is the idea behind Telescope. And there are others. - But, regardless of how smart the tools will be, the second dimensions remains a cognitive one. We do not know yet what is the best way, but it certainly isn't how the current industry-standard-tools make us work. In our environment we now have the luxury of exploring new possibilities because the environment is so radically different (and it will be even more different). There is no other environment I know that provides this opportunity, and I believe this is the place where we can change software development. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
On Fri, Jul 24, 2015 at 10:47 AM, Peter Uhnák <i.uhnak@gmail.com> 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...
participants (5)
-
Jan BlizniÄenko -
Peter Uhnák -
Thierry Goubier -
Tudor Girba -
Yuriy Tymchuk