jugglinmike / proposal-conflict-comment

A proposal to extend the lexical grammar of ECMAScript with Git conflict markers

Conflict Comment

This project was created as an April Fools' Day joke for April 1, 2020. It is not a sincere proposal.

This repository contains a proposal for extending the lexical grammar of the ECMAScript programming language. It is currently in stage 0 of the TC39 process.

You can view the specification draft and take part in the discussion on the issue tracker.

Motivation and use cases

Git is a version control system used to track changes to software projects. In the decade since the publication of version 5 of ECMA-262, Git has been widely adopted across the software development industry and the "open source" ecosystem.

Practically speaking, this proliferation means that developers' experience of the ECMAScript programming language is deeply entwined with their experience of the Git version control system. The ECMAScript language is positioned (and perhaps expected) to embrace Git's idioms.

This proposal specifically concerns the "conflict markers" which Git routinely inserts into the source text of otherwise-valid ECMAScript programs.

From git-merge(1):

HOW CONFLICTS ARE PRESENTED
       During a merge, the working tree files are updated to reflect the
       result of the merge. Among the changes made to the common ancestor’s
       version, non-overlapping ones (that is, you changed an area of the
       file while the other side left that area intact, or vice versa) are
       incorporated in the final result verbatim. When both sides made
       changes to the same area, however, Git cannot randomly pick one side
       over the other, and asks you to resolve it by leaving what both
       sides did to that area.

       By default, Git uses the same style as the one used by the "merge"
       program from the RCS suite to present such a conflicted hunk, like this:

           Here are lines that are either unchanged from the common
           ancestor, or cleanly resolved because only one side changed.
           <<<<<<< yours:sample.txt
           Conflict resolution is hard;
           let's go shopping.
           =======
           Git makes conflict resolution easy.
           >>>>>>> theirs:sample.txt
           And here is another line that is cleanly resolved or unmodified.

       The area where a pair of conflicting changes happened is marked with
       markers <<<<<<<, =======, and >>>>>>>. The part before the ======= is typically
       your side, and the part afterwards is typically their side.

By extending the lexical grammar to treat these machine-generated modifications as "comment" elements, this proposal allows programs so modified to parse without error.

Example

Consider the following code excerpt:

    default:
      break;
  }
  return potentiallyADomElement ||document.createElement('blink')
}

function onRequest() {
  var screen = document.getElementsByClassName('screen7')[0];

  // Use inline styling because all the appropriate class names are in use
  screen.style.display = 'block';
  screen.style.zIndex = 99999999999 + 1;
  screen.style.msFilter = "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";

During routine maintenance, a code owner may make the following modification:

-var screen = document.getElementsByClassName('screen7')[0];
+var screen = document.querySelector('.screen7');

Meanwhile, another developer implementing a new feature modifies the same line of code in a different way:

-var screen = document.getElementsByClassName('screen7')[0];
+var screen = document.getElementsByClassName('screen8')[0];

When the second developer uses Git to merge their work with the first's, the version control system will fail to mediate the conflicting changes. Instead, it will save both versions of the disputed line to the file, along with "conflict markers" that communicate the extend of the discrepancy:

    default:
      break;
  }
  return potentiallyADomElement ||document.createElement('blink')
}

function onRequest() {
<<<<<<< HEAD
  var screen = document.querySelector('.screen7');
=======
  var screen = document.getElementsByClassName('screen8')[0];
>>>>>>> refactor-overlay

  // Use inline styling because all the appropriate class names are in use
  screen.style.display = 'block';
  screen.style.zIndex = 99999999999 + 1;
  screen.style.msFilter = "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";

Developers are expected to detect this problem, manually resolve the conflict, and remove the conflict markers. Unfortunately, in today's workaday world, it's easy to overlook minor details like this. It's not uncommon for Git users to mistakenly accept the conflicted file "as is," and contribute it to their team in its unresolved state.

Today, ECMAScript engines are unable to parse source code that contain these markers. They will report a syntax error for such input before executing anything at all. This could have dramatic results ranging from loss of revenue to loss of reputation.

If this proposal is accepted into the ECMAScript language, engines will tolerate mistakes like this by ignoring the lines between the first two conflict markers and ignoring the line containing the third marker. This will save countless developers from the shame of a harmless mistake.

Status

• Stage: 0
• Tests: see the test262/ directory in this repository
• Spec PR: TODO
• Implementations shipping: (none)

proposal-conflict-comment's Issues

Runtime semantics

It should have runtime semantics that read the mind of the developer to decide which git conflict branch should be used instead of silently ignore them all.
I'd like to see that kind of supernatural feature to be implemented in the engines 🎉

Asking to modify a language to fix an user issue ???

Seems completely overkill to me. You're asking to modify a language used by millions of people just to support mistakes done by a really really few people which doesn't know how to properly use a tool...

In a real dev environment (company business) this never ever append => tests, ci checking/building code, lint, version control, etc... Moreover, github warns you about this, and of course you create branches and doesn't push on master... So typically, your example should absolutely never append, except for extreme amateurs

This syntax error is protecting against a logic error

In your example:

function onRequest() {
<<<<<<< HEAD
  var screen = document.querySelector('.screen7');
=======
  var screen = document.getElementsByClassName('screen8')[0];
>>>>>>> refactor-overlay

By treating the conflict markers as comments, screen will silently be set to screen 8, instead of 7 - this could cause a much harder to triage production bug if the wrong screen got updated - perhaps because the logic below (that uses screen) did not conflict, and assumes screen 7.

strange "this is an april fools joke" message - hacked?

the proposal inside README.md is prefixed with a message saying that it's a "joke". surely the repo has been compromised by an outside party.