<div dir="ltr"><div>Hi Ben,</div><div>MC does handle a method as an atom. So 2 branches changing the same method => conflict.</div><div>git has no idea of what a class or method is. It sort of handle lines of code as atom. This is arbitrary but works with most languages.</div><div>IMO, it's not a big problem, concurrent changes on one method require human review.<br></div><div><br></div><div>Problem of metadata in filetree mostly came from the fact that all-metadata of whole package was in a single line of a single file...</div><div>Even with that, Thierry Goubier did provide a git hook that did resolve 99% of the false metadata conflicts, it's just that it was never used/integrated.</div><div><a href="http://forum.world.st/Glass-git-merge-driver-for-FileTree-td4758204.html">http://forum.world.st/Glass-git-merge-driver-for-FileTree-td4758204.html</a></div><div><a href="https://github.com/ThierryGoubier/GitFileTree-MergeDriver">https://github.com/ThierryGoubier/GitFileTree-MergeDriver</a></div><div>The decision to kill metadata is understandable if in the long term you decide to rely EXCLUSIVELY on VCS metadata.</div><div>But it means that you EXPLICITELY do not want to support compatibility with MC.</div><div>That's what Eliot is calling passive aggressive.</div><div><br></div><div>So I don't buy the conflict argument.<br></div><div>In France we say: "quand on veut tuer son chien, on l'accuse de la rage".<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 14 janv. 2020 à 18:23, Ben Coman <<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>> a écrit :<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>
On Wed, 15 Jan 2020 at 01:18, Ben Coman <<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, 14 Jan 2020 at 20:55, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
>><br>
>><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>
><br>
><br>
> To simplify things with an analogous example, lets put aside Tonel and Metacello<br>
> and consider git's treatment of metadata in a basic file-out.<br>
><br>
> # SETUP TEST REPO<br>
><br>
> $ mkdir test & cd test<br>
> $ git init<br>
> $ git config --global <a href="http://user.name" rel="noreferrer" target="_blank">user.name</a> "Test"<br>
> $ git config --global user.email "<a href="mailto:test@test.com" target="_blank">test@test.com</a>"<br>
> $ cat > <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a> <<EOF<br>
> 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>
> EOF<br>
><br>
> $ git add <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a><br>
> $ git commit -m "First commit"<br>
> $ git branch b1<br>
> $ git branch b2<br>
> $ git branch b3<br>
> $ git branch b4<br>
><br>
> # FIRST EXPERIMENT, BASELINE AN UPDATE & MERGE WITHOUT TIMESTAMPS<br>
><br>
> $ git checkout b1<br>
> $ vi <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a><br>
> - self inform: 'line 1 branch master'.<br>
> + self inform: 'line 1 branch b1'.<br>
> $ git commit -am "line 1 branch b1"<br>
><br>
> $ git checkout b2<br>
> $ vi <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a><br>
> - self inform: 'line 1 branch master'.<br>
> + self inform: 'line 1 branch b3'.<br>
> $ git commit -am "line 1 branch b3"<br>
<br>
# CORRECTION, of course the moment I hit send I notice a copy-paste<br>
error. Obviously it should be...<br>
$ git checkout b2<br>
$ vi <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a><br>
- self inform: 'line 3 branch master'.<br>
+ self inform: 'line 3 branch b2'.<br>
$ git commit -am "line 3 branch b2"<br>
<br>
> $ git diff b1<br>
> $ git merge b1<br>
> $ cat <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a><br>
> ==> merged worked fine, no conflicts<br>
><br>
> # SECOND EXPERIMENT, UPDATE & MERGE WITH TIMESTAMPS<br>
><br>
> $ git checkout b3<br>
> $ vi <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a><br>
> -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'!<br>
> +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:10'!<br>
> - self inform: 'line 1 branch master'.<br>
> + self inform: 'line 1 branch b3'.<br>
> $ git commit -am "line 1 branch b3"<br>
><br>
> $ git checkout b4<br>
> $ vi <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a><br>
> -!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:00'!<br>
> +!MyClass methodsFor: 'example' stamp: 'Tester 01/01/2020 10:15'!<br>
> - self inform: 'line 3 branch master'.<br>
> + self inform: 'line 3 branch b4'.<br>
> $ git commit -am "line 3 branch b4"<br>
><br>
> $ git diff b1<br>
> $ git merge b1<br>
> $ cat <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a><br>
> ==> CONFLICT (content): Merge conflict in <a href="http://some.st" rel="noreferrer" target="_blank">some.st</a><br>
><br>
> $ git merge --abort<br>
><br>
><br>
> So naive question... How does Monticello deal with such a situation between b3 & b4?<br>
><br>
> Left as an exercise is pushing branches b3 & b4 to a git-service-provider,<br>
> then issue a PR merging b3 into master, followed up a PR merging b4 into master.<br>
><br>
> If you can work out how to easily get such timestamp merge conflicts to AUTO RESOLVE<br>
> on the remote git server used to merge PRs (i.e. GitHub, GitLab, etc),<br>
> in a way compatible with libgit, there may be a better case for calling B.S. on Tonel's lack of timestamps.<br>
><br>
> I do remember watching the Pharo community struggle for many months with the above issue<br>
> 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.<br>
> My memory of mail list discussions was that the decision to drop timestamps wasn't taken lightly,<br>
> but seemed like the only practical way to move forward into a git world.<br>
><br>
> HTH,<br>
> cheers -ben<br>
><br>
</blockquote></div>