| 1 |
On Mon, 12 Aug 2019 11:20:01 -0700 |
| 2 |
Alec Warner <antarus@g.o> wrote: |
| 3 |
|
| 4 |
> > And both of those can have "Fun" merge conflict issues due to the |
| 5 |
> > requirements around record delimiters and syntax, |
| 6 |
> > |
| 7 |
> |
| 8 |
> And this means what? That I might check something in that is broken? |
| 9 |
> How is this not true for any syntax we define? |
| 10 |
|
| 11 |
It leads git to the conclusion 2 different people edited the same line, |
| 12 |
which they did, technically. |
| 13 |
|
| 14 |
But the semantic change when viewed as a series of atomic units, each |
| 15 |
editor edited an element that was unrelated to the other. (On par with |
| 16 |
getting a conflict because line's 1 and lines 100 of the same file were |
| 17 |
edited by different people, that is, pretty much killing the point of |
| 18 |
automatic conflict resolution) |
| 19 |
|
| 20 |
This leads to conflicts that git can't solve on its own, when it could |
| 21 |
by simple format choice. ( And this leads to a place where somebody |
| 22 |
could fuck up the merge, like, having their merge tool fail and then |
| 23 |
managing to commit the conflict-markers. Been there. ) |
| 24 |
|
| 25 |
But the short version of it, is this should not generate conflicts: |
| 26 |
|
| 27 |
- User A edits last record of file |
| 28 |
- User B appends record to file |
| 29 |
|
| 30 |
Whereas with JSON at least, either the format demands it due to |
| 31 |
prohibiting the trailing ',', so: |
| 32 |
|
| 33 |
[ |
| 34 |
a, |
| 35 |
b, |
| 36 |
] |
| 37 |
|
| 38 |
Is illegal. |
| 39 |
|
| 40 |
You can kinda get around it by using left-side commas: |
| 41 |
|
| 42 |
[ |
| 43 |
b |
| 44 |
,c |
| 45 |
] |
| 46 |
|
| 47 |
But do you really want to standarize *that*? |
Archives