On Mon, 12 Aug 2019 11:20:01 -0700 Alec Warner <anta...@gentoo.org> wrote:
> > And both of those can have "Fun" merge conflict issues due to the > > requirements around record delimiters and syntax, > > > > And this means what? That I might check something in that is broken? > How is this not true for any syntax we define? It leads git to the conclusion 2 different people edited the same line, which they did, technically. But the semantic change when viewed as a series of atomic units, each editor edited an element that was unrelated to the other. (On par with getting a conflict because line's 1 and lines 100 of the same file were edited by different people, that is, pretty much killing the point of automatic conflict resolution) This leads to conflicts that git can't solve on its own, when it could by simple format choice. ( And this leads to a place where somebody could fuck up the merge, like, having their merge tool fail and then managing to commit the conflict-markers. Been there. ) But the short version of it, is this should not generate conflicts: - User A edits last record of file - User B appends record to file Whereas with JSON at least, either the format demands it due to prohibiting the trailing ',', so: [ a, b, ] Is illegal. You can kinda get around it by using left-side commas: [ b ,c ] But do you really want to standarize *that*?
pgpivF660S8SA.pgp
Description: OpenPGP digital signature
