3 ms·
The files holding the ASTs are append-only. So you get: PR #1: appended stuff PR #2: appended stuff So there is no merge conflict in the git sense.
by strbean 7y ago
The files holding the ASTs are append-only. So you get:
PR #1: appended stuff
PR #2: appended stuff
So there is no merge conflict in the git sense.
- alkonaut 7y agoIt seems to me that if we both edit the same function then we end up with three functions in store (original + two modified). Now obviously I want the main function to call my new version function and you want the main function to call your version. So in the end there is a conflict somewhere - even in the git sense. If that conflict always shows up in one single line saying what hash of the main function is the one to use - then it doesn’t seem like a huge improvement in terms of conflict handling. Conflicts bubble to the root hash. I assume they thought about this and have some sort of tooling for “traversing” conflicts from the root, choosing my function, your function, or allowing a merged function to be created.
- SideburnsOfDoom 7y ago> The files holding the ASTs are append-only. So you get: PR #1: appended stuff PR #2: appended stuff But that description also applies to git. Which could not avoid having to deal with conflicts.
- renox 7y agoI disagree: in #1 and #2, the mapping between the key and the function name are different, so there is a conflict.