<div dir="ltr"><div>Hi Eliot,</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 18. Feb. 2019 um 18:34 Uhr schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Esteban,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 4:06 AM Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><div><br>Thing is,  putting timestamps it will generate conflicts massively when there is no reason to it.<br></div></div></div></div></blockquote><div><br></div><div>How can this be true? Since a method's time stamp changes only when it is modified it will only produce a change where a method is changed.  I see no problem with this.</div></div></div></div></blockquote><div><br></div><div>When two people's changes to the same method are merged with Git (or on GitHub for that matter) there will be a conflict at the line that contains the timestamp. Even if the method source could be merged conflict-free. Moreover, none of the two original timestamps will be accurate for the merged version of the method, so in fact there *must* be a conflict. This is only alleviated by performing the merge in the IDE where a new timestamp could be generated for the merged method. For otherwise clean merges, this is probably unacceptable for people that just want to press the "merge" button on a pull request.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div></div><div><br><div>And Pharo can read that format but it will ignore all extensions. </div><div>Now, another problem is to WRITE: Pharo would write those packages in “pharo format” and that information would be lost. And in the case of VMMaker, if the idea is to be able to work on both sides, then Pharo needs to “honour” that format, it cannot just read it and ignore it later. So this creates an incompatibility that needs to be handled. </div></div></div></blockquote></div></div></div></blockquote><div><br></div><div>This is the reason why Pharo cannot just "not use" timestamps and yet support them. Every Pharo user on the team would eliminate the timestamps that the Squeak team members committed. Except if Pharo would allow to carry the existing timestamps around in the code model for Squeak, but it sounds like they are not willing to do that, are they?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><div><div><br></div><div>Anyway, as you can see my answer was not “not under any circumstances”. Was “no, because is not convenient”.</div></div></div></div></div></blockquote><div><br></div><div>It was still no.  And my request was clear.  I asked if you would allow Tonel to support timestamps, not that Pharo would use timestamps.  This avoids forking Tonel, which I see as essential (it is essential that Tonel *not* fork) for Tonel to be a format that can serve as an interchange between Squeak and Pharo.</div></div></div></div></blockquote><div><br></div><div>Kind regards,</div><div>Jakob</div><div><br></div><div>PS. Note that I am not on pharo-dev and do not wish to subscribe for just one thread, so I had to omit them from CC.</div></div></div>