RE: first-class conflicts?

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Nov 6, 2023, 22:34 UTC
Message-ID: <002901da1101$7d39a420$77acec60$@nexbridge.com>
In-Reply-To: <ef30a484525157579c64249a396f10ae@manjaro.org>

On November 6, 2023 5:01 PM, Dragan Simic wrote:

Show 6 quoted lines

>On 2023-11-06 22:17, Sandra Snan wrote:
>> Is this feature from jj also a good idea for git?
>> https://martinvonz.github.io/jj/v0.11.0/conflicts/
>
>Hmm, that's quite interesting, but frankly it makes little sense to me.
>See, the source code in a repository should always be in a compileable or

runnable

>state, in each and every commit, so going against that rule wouldn't make

much

>sense.  Just think about various CI/CD tools that also expect the same.

It seems to me, perhaps naively, that the longer a conflict persists in a repository, the greater the potential for chaotic results. There are, notably, at least two fundamental types of conflicts:

1. Content conflict, where a point in a file is modified in two (or n)
branches being combined, is what git tries to ensure never happens. The
longer such a conflict exists in a file, the greater the variance from a
buildable or consistent state will persist and will likely be increasingly
harder to resolve.

2. Semantic conflicts, where unrelated modification points cause
incompatibilities are much harder to resolve and quantify - many are, in
fact, undetectable from a computational standpoint (as in detecting general
semantic conflicts is an uncomputable problem). The longer those persist,
partly when they are missed by pull requests/code reviews, the more
persistent a defect can become.

3. I am avoiding matters such as code optimization conflicts which are
outside the scope of the proposal.

In either case, storing conflicts in the integration branches of a repository is, in my view, a bad thing that eventually can make the repository unsustainable. I will concede that keeping conflicts around in non-integration branches may have intellectual value for recording research and development progress.

This is just my opinion. Randall

-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400) NonStop(211288444200000000) -- In real life, I talk too much.