<div dir="ltr"><div dir="ltr"><div>Hi Ben,</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 19 janv. 2020 à 09:43, Ben Coman <<a href="mailto:btc@openinworld.com">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 Thu, 16 Jan 2020 at 06:47, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
><br>
><br>
> Hi Ben!<br>
><br>
> On Wed, 15 Jan 2020, Ben Coman wrote:<br>
><br>
> ><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>
> snip<br>
><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>
><br>
> Why do you want these to "AUTO RESOLVE"?<br>
> If the same method is modified in two different branches, it's a must to<br>
> check whether those changes are compatible or not, isn't it?<br>
<br>
Because the merge of PRs is happening on a CI server where there is no<br>
human interaction.<br>
Tests take care of the issue of compatibility.<br>
<br></blockquote><div>I have to disagree here.</div><div>Tests do not replace human review, they just complement it</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">
btw, Did you run through my example on your own system?<br>
If not, please do.  :)   Its easy to skim the text without getting a<br>
real feel for it,<br>
and indeed, in re-reading my example and my point doesn't leap out at me.<br>
<br>
My point was that that the FIRST EXPERIMENT demonstrates two branches<br>
with "different changes to the same method without updating the times<br>
stamp"<br>
doesn't cause a merge problem.  The result method contains both changes.<br>
<br>
The SECOND EXPERIMENT makes the identical changes, but this time<br>
updates the timestamp.  Two updates to the same-line causes a<br>
conflict.<br>
<br>
cheers -ben<br></blockquote><div> </div><div>Yes, we agree that in some cases line based diff may avoid some conflicts.</div><div>But as we said, we want human review anyway in case of such concurrent method change.</div><div>That's true that the non conflicting case would require one more commit or a rebase before merging the PR.<br></div><div>But in Smalltalk, methods are rather short, so how often is your crafted example going to happen in real world?<br></div></div></div>