>From the other thread:

Eliot Miranda <eliot.miranda at gmail.com> schrieb am Fr., 31. Jan. 2020,
14:26:




On Jan 31, 2020, at 12:08 AM, Jakob Reschke <forums.jakob at resfarm.de> wrote:


Sounds as if Pharo had dropped the timestamps from the Monticello model
completely. Or all reading and writing of them.


That’s indeed what they have done.  It’s easily worked around, as my
modification to Monticello shows.


Under these circumstances, maybe it even makes sense to ignore and exclude
non-changes without timestamps by default.




Guillermo Polito <guillermopolito at gmail.com> schrieb am Mo., 27. Jan. 2020,
14:00:


Inspecting the mcz, I see the timestamps were gone, sorry.
Still, I think the problem is deeper than git/not git. Because when doing
the patch I carefully loaded latest VMMaker.oscog version.
I supposed that forcing loading in monticello would reload everything. I
(wrongly) guessed it should have installed timestamps too.
Then I applied my change from there.

Even just now, I got a latest fresh pharo9,
 - downloaded latest VMMaker from source.squeak.org
 - made a diff and a merge with the version I generated in the inbox
    => both empty => I cannot see problems related to missing timestamps in
the UI :/
And no git was involved *at all* here.

I was maybe supposed to see changes in timestamps here? Does MC diff show
that at all?
Now that I think about it, I don’t have any memories of it. But that could
have helped me spot the problem before.
Maybe I could patch MC diff in Pharo to take timestamps into account?


Jakob Reschke <forums.jakob at resfarm.de> schrieb am Do., 30. Jan. 2020,
07:48:

> Chris Muller <asqueaker at gmail.com> schrieb am Mi., 29. Jan. 2020, 23:40:
>
>> On Wed, Jan 29, 2020 at 1:04 AM Jakob Reschke <forums.jakob at resfarm.de>
>> wrote:
>>
>>> Chris Muller <asqueaker at gmail.com> schrieb am Mi., 29. Jan. 2020, 03:57:
>>>
>>>>
>>>> It's important this feature does not get inherited by SaveDialog since
>>>> the functionality could be harmful if used there
>>>>
>>>
>>> How so? What is bad about wittingly ignoring non-changes during save?
>>> You called it pollution yourself.
>>>
>>
>> Jakob, your language is confusing because "Ignore" is the other command
>> there that, yes, would cause them to not be committed.
>>
>> But what is being added is a 'filter out unchanged methods from the
>> list...', which, IIUC, would only remove them from the list, making them
>> invisible, but not "Ignore" them.  So, if used on the Save dialog, would
>> they be included in the commit?
>>
>
> Alright if it does not work there it should be fixed in the second
> iteration of course. I didn't test it. Ignoring instead of removing on save
> sounds reasonable, then you can change your mind later (although in this
> case, why would you...).
>
> I suppose this can be covered by a unit test.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200131/f03eae3b/attachment.html>