<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 14 Jan 2020 at 20:55, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</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"> <br>
Hi Torsten<br>
<br>
On Mon, 13 Jan 2020, Torsten Bergmann wrote:<br>
<br>
> <br>
> Hi Eliot,<br>
><br>
>> there's a simpler solution. We simply delete Alien-Core-TorstenBergmann.101<br>
><br>
> Yes - no problem with that and thanks for taking care. But a copy might exist still in local Monticello caches<br>
> on user side.<br>
><br>
> So an Alien-Core-eem.102 as Dave suggested would nonetheless be the safest addition to compensate<br>
> the Alien-Core-eem.101.mcz (where 101 version was used unfortunately a second time).<br>
><br>
>> I'll do that by Monday if no one objects. I'm sure Torsten meant no harm and was<br>
>> unaware of the issue.<br>
><br>
> Yes - for the timestamp I did not notice directly (or even forgot because I guess I just had a newer Pharo<br>
> image on the machine which was already switched git but still includes MCZ tools).<br>
><br>
> But if you really require the timestamps explicitly on each method for the VMMaker / Alien packages<br>
> then it means one is only allowed to use Squeak or old Pharo versions to contribute / commit and<br>
> VM development will never move away from MCZs in all our lifetime.<br>
><br>
> The Pharo tools do not have the timestamp in MCZs anymore due to the switch to GIT. Because having the timestamp in the file<br>
> format directly would always mean a change/conflict in the diffs of git anytime - even if there is no real code change<br>
> on the method or class itself.<br>
<br>
Can you explain how keeping the timestamps as they are in Monticello would <br>
introduce change/conflict in git?<br>
Those are just static strings unless you change the method, aren't they?<br></blockquote><div><br></div><div>
To simplify things with an analogous example, lets put aside Tonel and Metacello </div><div>and consider git's treatment of metadata in a basic file-out.</div><div><br></div><div># SETUP TEST REPO</div><div><br></div><div>$ mkdir test & cd test</div><div>$ git init</div><div>$ git config --global <a href="http://user.name">user.name</a> "Test"</div><div>$ git config --global user.email "<a href="mailto:test@test.com">test@test.com</a>"</div><div>$ cat > <a href="http://some.st">some.st</a> <<EOF</div><div>Object subclass: #MyClass<br> instanceVariableNames: ''<br> classVariableNames: ''<br> poolDictionaries: ''<br> category: 'Example'!<br><br>!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'!<br>method1<br> self inform: 'line 1 branch master'.<br> self inform: 'line 2 branch master'.<br> self inform: 'line 3 branch master'.<br> self inform: 'line 4 branch master'.<br>! !<br></div><div>EOF</div><div><br></div><div>$ git add <a href="http://some.st">some.st</a></div><div>$ git commit -m "First commit"</div><div>$ git branch b1</div><div>$ git branch b2</div><div><div>$ git branch b3</div><div></div></div><div><div><div>$ git branch b4</div><div></div></div><div></div></div><div><br></div><div># FIRST EXPERIMENT, BASELINE AN UPDATE & MERGE WITHOUT TIMESTAMPS</div><div><br></div><div>$ git checkout b1</div><div>$ vi <a href="http://some.st">some.st</a> </div><div> - self inform: 'line 1 branch master'.</div><div> + self inform: 'line 1 branch b1'.</div><div></div><div>$ git commit -am "line 1 branch b1"</div><div><br></div><div>$ git checkout b2</div><div><div>$ vi <a href="http://some.st">some.st</a></div><div> - self inform: 'line 3 branch master'.</div><div> + self inform: 'line 3 branch b3'.</div><div></div><div></div><div>$ git commit -am "line 3 branch b3"</div><div><br></div><div>$ git diff b1</div><div>$ git merge b1</div><div></div></div><div>$ cat <a href="http://some.st">some.st</a></div><div> ==> merged worked fine, no conflicts</div><div> <br></div><div><div># SECOND EXPERIMENT, UPDATE & MERGE WITH TIMESTAMPS</div><div></div></div><div><br></div><div>$ git checkout b3</div><div><div>$ vi <a href="http://some.st">some.st</a> </div><div><div> -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'!<br></div><div></div><div> +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:10'!<br></div><div></div><div> - self inform: 'line 1 branch master'.</div><div> + self inform: 'line 1 branch b3'.</div><div></div><div></div><div></div><div>$ git commit -am "line 1 branch b3"</div><div></div></div><div><br></div><div><div>$ git checkout b4</div><div><div>$ vi <a href="http://some.st">some.st</a> </div><div><div> -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'!<br></div><div></div><div> +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:15'!<br></div><div></div><div></div><div> - self inform: 'line 3 branch master'.</div><div> + self inform: 'line 3 branch b4'.</div><div></div><div></div><div></div><div>$ git commit -am "line 3 branch b4"</div><div><br></div><div><div><div>$ git diff b1</div><div>$ git merge b1</div><div></div></div><div>$ cat <a href="http://some.st">some.st</a></div><div> ==> CONFLICT (content): Merge conflict in <a href="http://some.st">some.st</a></div></div><div><br></div><div><div><div>$ git merge --abort</div><div></div></div><div></div></div><div><br></div><div><br></div><div>So naive question... How does Monticello deal with such a situation between b3 & b4?</div><div><br></div><div>Left as an exercise is pushing branches b3 & b4 to a git-service-provider, </div><div>then issue a PR merging b3 into master, followed up a PR merging b4 into master. </div><div><br></div><div>If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE <br></div><div>on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc), </div><div>in a way compatible with libgit, there may be a better case for calling B.S. on Tonel's lack of timestamps. </div><div><br></div><div>I do remember watching the Pharo community struggle for many months with the above issue </div><div>and it was really impeding git uptake by users. I know I got burnt and I didn't transition to using git from within Pharo until it was resolved by Tonel.</div><div>My memory of mail list discussions was that the decision to drop timestamps wasn't taken lightly, </div><div>but seemed like the only practical way to move forward into a git world. </div><div><br></div><div>HTH,</div><div>cheers -ben</div><div></div><div><br></div><div></div></div><div></div></div></div><div></div></div></div></div>