From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A2411138334 for ; Mon, 12 Aug 2019 19:03:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8DB41E07D7; Mon, 12 Aug 2019 19:03:20 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3F4F9E078A for ; Mon, 12 Aug 2019 19:03:20 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id 77B9B3499B5 for ; Mon, 12 Aug 2019 19:03:17 +0000 (UTC) Date: Tue, 13 Aug 2019 07:01:48 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Moving UID/GID assignments to api.gentoo.org Message-ID: <20190813070148.2f2fdf9f@katipo2.lan> In-Reply-To: References: <87a7f00e6badd6e0c4247aa8853c4934bbae092e.camel@gentoo.org> <20190810204917.GA2657@linux1.home> <20190811194828.GA2329@linux1.home> <20190811225344.GA3438@linux1.home> <71b49943bc100290219ce26312870de74741ce6a.camel@gentoo.org> <20190813055804.4b804d1a@katipo2.lan> Organization: Gentoo X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/pgaA1rwmL+CdLkY2bSAS0n="; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Archives-Salt: 5bb34241-414d-4de5-abed-1ba384ec68ea X-Archives-Hash: b03ad5382a639113e85c3e6c25042025 --Sig_/pgaA1rwmL+CdLkY2bSAS0n= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 12 Aug 2019 11:20:01 -0700 Alec Warner wrote: > > And both of those can have "Fun" merge conflict issues due to the > > requirements around record delimiters and syntax, > > =20 >=20 > 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: [=20 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*? --Sig_/pgaA1rwmL+CdLkY2bSAS0n= Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgdrME8Lrmai3DXYJda6SGagVg7UFAl1Rt6gACgkQda6SGagV g7WrZw/+MkpNJITYXdI9AVE0VjL5f6P5kVfPyncrONWhL+viY+m8qRaqhCX38qgv cwIvJjHp5EDVkVLLabZ+koUzCG/rOfNms4BeJbpnbfYc96EnsI0LrzW5KZmq3Esy vqtj2y26FUcKG8mP1VXKIIUHoKDkV1MDRqjsQcC9SoXN7cQMwKNoladrkaIqX8fY 3UUcqtmES5oHDNpCqcDBz20k3peXS7Qh9cB+wP851P57CZQGuV0Qh0qz5PcUWiau MnmHuG3bMChquHgfiJgQjbFKwbXvzhGmEF0bbL8ICrVxHMVKeWtSc3eXLL8lLDgv E5u3JcgIJ1IOD8rQbf7+6/oxvmZZE9bK33iCL3bj7gnUdZRAy41wWLKD+CEGbmuO I/uAWBk1W5uPrdl1WBmKHWD6fL8ki4AYRgenSzf2WSFpj+9KiotMUFqc/mWH+tPT dGxis3r0FVGc95aCdjQqG0wZLaZSTLH5hhztA20Xdry3EB4AngXQYjKaLemwNDpL l2kKweqEWDKFCDMjdCyOr/Qskbq3MVOM3y/TqpnrkIEPoixtgS3yXBvZjQMGwsMx qY7KQnt3wXZm7dWnkCFxwVICT39qWDfBOAe2OTvtLVFYZYCOwGwKOjARny7nkarZ tTHXbFnFtflRSTfK4PJHJlPuN+nx66VGOW7z2QN/Qb4+1OX3OWA= =oGVH -----END PGP SIGNATURE----- --Sig_/pgaA1rwmL+CdLkY2bSAS0n=--