🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
timo i'm having this ridiculous idea right now 06:55
we warn whenever we see merge conflict markers, right?
timo what if we offered the user a way to always take the before or always take the after path (or maybe a piece of code to make the decision on a filename/line number basis, or based on the conflict lines themselves?), so you'll end up with being able to test your code with a partially resolved merge conflict 06:56
timo has anybody recommended git imerge to y'all yet? 07:49
[Coke] -1 for any more magic based on merge conflict markers; what if you have multiple instance, how do you answer the question for each one? 14:42
vrurg Agree. This is the road where we end up having a whole lot of infrastructure for different SCM built into the compiler itself. 15:02
I'd say a tool would do any kind of job like that better than a compiler would. 15:03
timo do different scm actually have noticeably different conflict markers? 16:00
but yeah, it's not actually important to have this %)
Voldenet it's useful to recognize that because conflict markers in heredocs are not going to be errors 16:14
perl recognizes such markers: perl -e '<<<<<<<' 16:16
> Version control conflict marker at -e line 1, near "<<<<<<<"
gcc recognizes that as well, clang doesn't 16:17
(Ok, clang recognizes only proper syntax as version control conflict marker) 16:19
Voldenet this made me wonder why `<<<<<<< HEAD` in the code isn't immediately marked as a failure 16:56