On November 6, 2023 5:01 PM, Dragan Simic wrote: >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.
