{"slug": "dsa-application-in-real-life-how-git-diff-works-lcs-intuition-myers-algorithm", "title": "DSA Application in Real Life: How Git Diff Works: LCS Intuition, Myers Algorithm, and Real Code Changes", "summary": "The article explains that Git's `diff` functionality is powered by the Longest Common Subsequence (LCS) algorithm, which treats file content as sequences of lines to identify what has been added, removed, or unchanged. It contrasts a naive line-by-line comparison with the LCS approach, demonstrating how LCS correctly identifies that only one line was inserted in a code example, while also noting that Git uses the more efficient Myers diff algorithm rather than the classic O(m×n) dynamic programming solution.", "body_md": "# The Algorithm Hiding Behind `git diff`\n\nYou've run `git diff`\n\nhundreds of times.\n\nRed lines. Green lines. Done.\n\nBut have you ever stopped and asked — *what algorithm is actually doing that?*\n\nIt turns out, the idea is closely related to one of the most classic problems in computer science: **Longest Common Subsequence**.\n\nIn this article, we'll explore how Git-style diffing works, why LCS is the right mental model, how the actual algorithm Git uses — **Myers diff** — connects to it, and what tradeoffs real tools make when choosing a diff algorithm.\n\nThis is the first article in my series **\"DSA Application in Real Life\"** — where I explore how common data structures and algorithms power the tools developers use every day.\n\n## The Problem Git Is Solving\n\nImagine we have an old version of a file:\n\n```\nfunction add(a, b) {\n  return a + b;\n}\n```\n\nThen we update it:\n\n```\nfunction addNumbers(a, b) {\n  return a + b;\n}\n```\n\nWhen we run `git diff`\n\n, Git shows:\n\n```\n-function add(a, b) {\n+function addNumbers(a, b) {\n   return a + b;\n }\n```\n\nThis looks obvious to us as humans. Only the function name changed.\n\nBut Git does not \"understand\" JavaScript the way we do. At the diffing level, Git treats the file as a **sequence of lines**. Its job is to compare two sequences and decide:\n\n- Which lines stayed the same?\n- Which lines were deleted?\n- Which lines were added?\n\nThis is a sequence comparison problem — and that's exactly where LCS comes in.\n\n## Why Simple Line-by-Line Comparison Is Not Enough\n\nA beginner might think Git just compares files line by line:\n\n```\nOld line 1 vs New line 1\nOld line 2 vs New line 2\nOld line 3 vs New line 3\n```\n\nThis works only when changes happen at the same position. But real code changes are rarely that simple.\n\nConsider this old file:\n\n```\nlogin()\nvalidate()\nsave()\nlogout()\n```\n\nNow we insert one new line:\n\n```\nlogin()\ncheckPermission()\nvalidate()\nsave()\nlogout()\n```\n\nA naive line-by-line comparison would produce:\n\n```\nOld: login()      New: login()            same\nOld: validate()   New: checkPermission()  different\nOld: save()       New: validate()         different\nOld: logout()     New: save()             different\nOld: (nothing)    New: logout()           added\n```\n\nThat makes it look like almost the entire file changed — which is completely wrong. Only one line was added.\n\nA smarter approach does not compare by position only. It first finds what stayed common between the two files.\n\nThat is the LCS idea.\n\n## LCS: The Mental Model Behind Diffing\n\n**LCS** stands for **Longest Common Subsequence**.\n\nA subsequence means you can pick elements from a sequence while keeping their relative order — but they do not need to be adjacent.\n\nExample:\n\n```\nOld = [A, B, C, D]\nNew = [A, C, E, D]\n```\n\nThe longest common subsequence is:\n\n```\n[A, C, D]\n```\n\nBecause `A`\n\n, `C`\n\n, and `D`\n\nappear in both sequences in the same order.\n\nApplied to file diffing, the lines of each file become the sequences:\n\n```\nOld = [login(), validate(), save(), logout()]\nNew = [login(), checkPermission(), validate(), save(), logout()]\n```\n\nThe LCS is:\n\n```\n[login(), validate(), save(), logout()]\n```\n\nNow Git-style diffing can reason:\n\n- These lines are\n**common**→ unchanged -\n`checkPermission()`\n\nis only in the new file → added\n\nResult:\n\n```\n login()\n+checkPermission()\n validate()\n save()\n logout()\n```\n\nThat's the core idea.\n\n## The Actual LCS Algorithm with Code\n\nHere's the classic dynamic programming solution you've likely seen in competitive programming:\n\n``` python\ndef lcs_length(A, B):\n    m, n = len(A), len(B)\n\n    # dp[i][j] = LCS length of A[:i] and B[:j]\n    dp = [[0] * (n + 1) for _ in range(m + 1)]\n\n    for i in range(1, m + 1):\n        for j in range(1, n + 1):\n            if A[i - 1] == B[j - 1]:\n                dp[i][j] = dp[i - 1][j - 1] + 1\n            else:\n                dp[i][j] = max(dp[i - 1][j], dp[i][j - 1])\n\n    return dp[m][n]\n```\n\nFor sequences:\n\n```\nA = [A, B, C, D]\nB = [A, C, E, D]\n```\n\nThe DP table looks like this:\n\n```\n     \"\"  A   C   E   D\n\"\"  [ 0   0   0   0   0 ]\nA   [ 0   1   1   1   1 ]\nB   [ 0   1   1   1   1 ]\nC   [ 0   1   2   2   2 ]\nD   [ 0   1   2   2   3 ]\n```\n\nThe answer is:\n\n```\ndp[4][4] = 3\n```\n\nSo the LCS length is `3`\n\n, and the LCS is:\n\n```\n[A, C, D]\n```\n\n**Time complexity:** `O(m × n)`\n\n**Space complexity:** `O(m × n)`\n\nFor large files, this gets expensive — which is why Git does not use textbook LCS directly.\n\n## Reconstructing the LCS from the DP Table\n\nThe DP table gives us the length of the LCS.\n\nBut to build an actual diff, we also need the common lines themselves.\n\nWe can get them by backtracking from the bottom-right corner of the table.\n\n``` python\ndef build_lcs(A, B):\n    m, n = len(A), len(B)\n\n    dp = [[0] * (n + 1) for _ in range(m + 1)]\n\n    # Build DP table\n    for i in range(1, m + 1):\n        for j in range(1, n + 1):\n            if A[i - 1] == B[j - 1]:\n                dp[i][j] = dp[i - 1][j - 1] + 1\n            else:\n                dp[i][j] = max(dp[i - 1][j], dp[i][j - 1])\n\n    # Backtrack to reconstruct the actual LCS\n    lcs = []\n    i, j = m, n\n\n    while i > 0 and j > 0:\n        if A[i - 1] == B[j - 1]:\n            lcs.append(A[i - 1])\n            i -= 1\n            j -= 1\n        elif dp[i - 1][j] >= dp[i][j - 1]:\n            i -= 1\n        else:\n            j -= 1\n\n    return lcs[::-1]\n\nold_file = [\"A\", \"B\", \"C\", \"D\"]\nnew_file = [\"A\", \"C\", \"E\", \"D\"]\n\nprint(build_lcs(old_file, new_file))\n# Output: ['A', 'C', 'D']\n```\n\nNow we do not only know the LCS length. We also know the actual common lines.\n\nThat is what lets us decide which lines stayed unchanged, which lines were deleted, and which lines were added.\n\n## How LCS Builds the Diff\n\nOnce you know the LCS, building the diff becomes straightforward:\n\n- Lines in the LCS → unchanged\n- Lines in old but not in the LCS → deleted\n- Lines in new but not in the LCS → added\n\nExample:\n\n```\nOld = [A, B, C, D]\nNew = [A, C, E, D]\nLCS = [A, C, D]\n\nB is only in Old  → deleted\nE is only in New  → added\n```\n\nDiff output:\n\n```\n A\n-B\n C\n+E\n D\n```\n\nThis is the basic shape of what Git, GitHub pull requests, VS Code comparison, and merge tools show: unchanged lines, deleted lines, and added lines.\n\n## Does Git Actually Use Textbook LCS?\n\nNot directly.\n\nGit's default algorithm is **Myers diff** — and it solves a slightly different but deeply related problem called the **Shortest Edit Script**.\n\nThe Shortest Edit Script asks:\n\nWhat is the smallest number of insertions and deletions needed to transform the old file into the new file?\n\nLCS and Shortest Edit Script are closely connected.\n\nLCS asks:\n\nWhat is the longest structure that stayed the same?\n\nShortest Edit Script asks:\n\nWhat is the smallest set of changes needed to transform one sequence into another?\n\nWhen only insertions and deletions are allowed, minimizing the edit script is mathematically related to maximizing the LCS length.\n\nFor two sequences with lengths `m`\n\nand `n`\n\n:\n\n```\nedit distance = m + n - 2 × LCS length\n```\n\nSo yes, they are two sides of the same coin — but they approach the problem from different directions.\n\nWhen we say \"Git uses LCS-based diffing,\" the accurate meaning is:\n\nGit's diffing is based on sequence-comparison ideas rooted in LCS, but its default implementation uses Myers' shortest edit script algorithm, which is faster in practice.\n\n## How Myers Diff Actually Works\n\nMyers models the diff problem as a graph search.\n\nImagine a grid where:\n\n- The X-axis represents lines of the\n**old** file - The Y-axis represents lines of the\n**new** file - Moving right means deleting a line from the old file\n- Moving down means inserting a line from the new file\n- Moving diagonally means the lines match, so no edit is needed\n\nFor:\n\n```\nOld = [A, B, C, D]\nNew = [A, C, E, D]\n```\n\nThe matching positions are:\n\n```\nA matches A\nC matches C\nD matches D\n```\n\nA simplified grid looks like this:\n\n```\n          Old\n        A    B    C    D\n      ┌────┬────┬────┬────┐\nNew A │╲   │    │    │    │\n      ├────┼────┼────┼────┤\n    C │    │    │╲   │    │\n      ├────┼────┼────┼────┤\n    E │    │    │    │    │\n      ├────┼────┼────┼────┤\n    D │    │    │    │╲   │\n      └────┴────┴────┴────┘\n```\n\nThe diagonal marks show where the two sequences have the same line.\n\nBut the important part is not only the matching cells.\n\nThe important part is the **path** from the top-left corner to the bottom-right corner.\n\nFor this example, one shortest path is:\n\n```\n(0,0)\n  │\n  ├─ diagonal: A matches A\n  │\n(1,1)\n  │\n  ├─ right: delete B\n  │\n(2,1)\n  │\n  ├─ diagonal: C matches C\n  │\n(3,2)\n  │\n  ├─ down: insert E\n  │\n(3,3)\n  │\n  ├─ diagonal: D matches D\n  │\n(4,4)\n```\n\nSo the path is:\n\n```\ndiagonal → right → diagonal → down → diagonal\n```\n\nWhich means:\n\n```\nKeep A\nDelete B\nKeep C\nInsert E\nKeep D\n```\n\nNow let's walk through that path step by step.\n\n### Step 1: Match `A`\n\nBoth files start with `A`\n\n, so Myers can move diagonally.\n\n```\nOld: A B C D\nNew: A C E D\n\nMatch: A\n```\n\nNo edit is needed.\n\n### Step 2: Delete `B`\n\nAfter `A`\n\n, the old file has `B`\n\n, but the new file has `C`\n\n.\n\nThey do not match, so one shortest path deletes `B`\n\n.\n\n```\n-B\n```\n\n### Step 3: Match `C`\n\nNow both sides line up at `C`\n\n, so Myers moves diagonally again.\n\n```\nMatch: C\n```\n\n### Step 4: Insert `E`\n\nAfter `C`\n\n, the new file has `E`\n\n, but the old file moves toward `D`\n\n.\n\nSo Myers inserts `E`\n\n.\n\n```\n+E\n```\n\n### Step 5: Match `D`\n\nFinally, both files match again at `D`\n\n.\n\nThe final shortest edit script is:\n\n```\n A\n-B\n C\n+E\n D\n```\n\nIn this example, the shortest edit script has only two edits:\n\n```\nDelete B\nInsert E\n```\n\nSo here, `D = 2`\n\n.\n\nThat is the key idea behind Myers.\n\nIt is not randomly comparing lines.\n\nIt is searching the edit graph for the shortest path that converts one sequence into another.\n\nThe path with the fewest right and down moves gives the shortest edit script.\n\nDiagonal moves are free because they represent lines that already match.\n\nThe algorithm is commonly described as:\n\n```\nTime complexity: O(ND)\n```\n\nWhere:\n\n-\n`N`\n\nis the total number of lines across both files -\n`D`\n\nis the size of the shortest edit script\n\nIn simple words, `D`\n\nmeans how many insertions and deletions are needed to transform the old file into the new file.\n\nFor space complexity, it depends on the implementation:\n\n```\nCommon Myers implementation: O(N)\nLinear-space Myers variant: O(D)\n```\n\nThis is why Myers performs very well when two files are mostly similar, which is the common case in real codebases.\n\nInstead of comparing every possible pair of lines like textbook LCS DP, Myers focuses on finding a short path of edits between the two versions.\n\n## Diff as an Edit Script\n\nLet's walk through a concrete edit script:\n\n```\nOld file → [A, B, C, D]\nNew file → [A, C, E, D]\n```\n\nStep 1: Delete `B`\n\n```\nA, C, D\n```\n\nStep 2: Insert `E`\n\nafter `C`\n\n```\nA, C, E, D\n```\n\nEdit script:\n\n```\nDelete B, Insert E\n```\n\nThat is just two operations.\n\nGit-style diff output:\n\n```\n A\n-B\n C\n+E\n D\n```\n\nClean, minimal, and easy to understand.\n\n## Why This Matters in Real Development\n\nWhen we review code, we're not just looking at text changes — we're trying to understand intent.\n\nA good diff makes that easy:\n\n```\n function calculateTotal(items) {\n-  return items.length;\n+  return items.reduce((sum, item) => sum + item.price, 0);\n }\n```\n\nAny reviewer immediately understands: the old code counted items, and the new code sums their prices.\n\nA bad diff creates noise and confusion.\n\nThat's why diff algorithms matter. They are not only about correctness. They are also about readability.\n\n## The Tradeoff: Shortest Diff vs Most Readable Diff\n\nThe smallest diff is not always the most readable one — especially in code with repeated patterns:\n\n```\nif (user) {\n  return true;\n}\n\nif (admin) {\n  return true;\n}\n\nif (owner) {\n  return true;\n}\n```\n\nWhen many lines look similar, a diff algorithm can match the wrong lines.\n\nThe result may be technically correct, but hard to read.\n\nThat's why Git ships multiple diff algorithms.\n\n## Git's Four Diff Algorithms\n\n```\ngit diff --diff-algorithm=myers      # default\ngit diff --diff-algorithm=minimal\ngit diff --diff-algorithm=patience\ngit diff --diff-algorithm=histogram\n```\n\nHere's what each one does and when to use it.\n\n### Myers\n\nFast and generally good.\n\nThis is what runs when you just type:\n\n```\ngit diff\n```\n\nBest for everyday use.\n\n### Minimal\n\nTries harder to find the smallest possible diff.\n\nIt can be slower, but useful when patch size matters.\n\n### Patience\n\nPrioritizes human readability.\n\nIt matches unique lines first, which helps avoid false alignments on repeated code.\n\nBest for reviewing refactors or moved code blocks.\n\n### Histogram\n\nAn evolution of Patience that also handles low-frequency lines well.\n\nIt often produces readable output for real codebases. Some developers prefer setting it as their global default because it can make source code diffs easier to review.\n\nTo set Histogram as your global default:\n\n```\ngit config --global diff.algorithm histogram\n```\n\n## Myers vs Patience Diff\n\nMyers is very good at finding a short edit script.\n\nBut sometimes the shortest diff is not the most readable diff.\n\nThis usually happens when a file has repeated or similar-looking lines. In that case, the algorithm may choose matches that are technically valid but not ideal for human review.\n\nConsider this example.\n\nOld version:\n\n``` python\ndef validate_user(user):\n    if not user.email:\n        return False\n    return True\n\ndef save_user(user):\n    database.save(user)\n\ndef validate_admin(admin):\n    if not admin.email:\n        return False\n    return True\n```\n\nNew version:\n\n``` python\ndef validate_admin(admin):\n    if not admin.email:\n        return False\n    return True\n\ndef validate_user(user):\n    if not user.email:\n        return False\n    return True\n\ndef save_user(user):\n    database.save(user)\n```\n\nHere, `validate_admin`\n\nmoved from the bottom to the top.\n\nBecause the functions contain repeated lines like:\n\n```\nreturn False\nreturn True\n```\n\na shortest-diff algorithm can sometimes align the repeated lines in a confusing way.\n\nA Myers-style diff may produce a technically correct result like this:\n\n``` python\n+def validate_admin(admin):\n+    if not admin.email:\n+        return False\n+    return True\n+\n def validate_user(user):\n     if not user.email:\n         return False\n     return True\n\n def save_user(user):\n     database.save(user)\n-\n-def validate_admin(admin):\n-    if not admin.email:\n-        return False\n-    return True\n```\n\nThis output is correct: it shows that `validate_admin`\n\nwas added at the top and removed from the bottom.\n\nBut for a reviewer, the important idea is simpler:\n\nOne function moved position.\n\nPatience diff tries to make this kind of refactor easier to read by first looking for unique lines as anchors, such as:\n\n``` python\ndef validate_user(user):\ndef save_user(user):\ndef validate_admin(admin):\n```\n\nThese unique lines help the algorithm avoid matching only repeated lines like `return False`\n\nand `return True`\n\n.\n\nFor this small example, Patience may still produce an output that looks very similar to Myers:\n\n``` python\n+def validate_admin(admin):\n+    if not admin.email:\n+        return False\n+    return True\n+\n def validate_user(user):\n     if not user.email:\n         return False\n     return True\n\n def save_user(user):\n     database.save(user)\n-\n-def validate_admin(admin):\n-    if not admin.email:\n-        return False\n-    return True\n```\n\nSo the important point is not that Patience magically shows a special \"move\" operation.\n\nGit diffs are still usually represented as additions and deletions.\n\nThe real benefit of Patience appears more clearly in larger refactors, especially when a file has many repeated lines such as:\n\n```\nreturn False\nreturn True\nelse:\nbreak\ncontinue\n}\n```\n\nIn those cases, Myers may match repeated lines too aggressively, while Patience prefers stronger unique anchors. That often makes the final diff easier for humans to review.\n\nThe exact output can vary depending on file context and Git version, but the idea is the same:\n\n- Myers focuses on finding a short edit script.\n- Patience focuses more on stable, unique anchors.\n- The shortest diff is not always the clearest diff.\n\n## Algorithm Complexity Summary\n\n| Algorithm | Rough Idea | Best For |\n|---|---|---|\n| Textbook LCS DP |\n`O(m × n)` time and space |\nLearning the concept |\n| Myers diff |\n`O(ND)` in the common description |\nDefault everyday diffs |\n| Minimal | Spends extra work to reduce diff size | Smaller patches |\n| Patience | Uses unique lines as anchors | Refactors / moved blocks |\n| Histogram | Extends Patience using low-frequency lines | Often readable code diffs |\n\nWhere:\n\n-\n`m`\n\n= number of lines in the old file -\n`n`\n\n= number of lines in the new file -\n`N`\n\n= total number of lines across both files -\n`D`\n\n= size of the shortest edit script\n\n## Where the DSA Is Hiding\n\nIn competitive programming, LCS is a textbook DP problem.\n\nIn the real world, the same idea appears in:\n\n```\nGit diff\nGitHub pull request review\nVS Code file comparison\nMerge conflict resolution\nGoogle Docs version history\nCode review platforms\nPatch generation\n```\n\nThe input changes — lines of code, words in a document, DOM nodes in a UI, events in a timeline — but the core question is always the same:\n\nWhat stayed the same, and what changed?\n\n## A Real-World Developer Example\n\nOld code:\n\n``` js\nfunction createUser(name, email) {\n  const user = { name, email };\n  saveUser(user);\n  return user;\n}\n```\n\nNew code:\n\n``` js\nfunction createUser(name, email, role) {\n  const user = { name, email, role };\n  validateUser(user);\n  saveUser(user);\n  return user;\n}\n```\n\nA well-tuned diff shows:\n\n```\n-function createUser(name, email) {\n+function createUser(name, email, role) {\n-  const user = { name, email };\n+  const user = { name, email, role };\n+  validateUser(user);\n   saveUser(user);\n   return user;\n }\n```\n\nAny reviewer immediately understands:\n\n- a\n`role`\n\nparameter was added - the role is stored on the user object\n- validation was introduced before saving\n\nThat's the value of a good diff algorithm.\n\nIt is not just computing differences. It is helping humans understand change.\n\n## Why Git Usually Works at the Line Level\n\nBy default, Git usually presents diffs at the line level because source code is naturally organized line by line.\n\nFor example, if we change this line:\n\n``` js\n-const total = price * quantity;\n+const total = price * quantity * tax;\n```\n\nA character-level diff could say that only `* tax`\n\nwas appended.\n\nThat is more precise, but precision is not always the same as readability.\n\nIn real code reviews, developers usually care about which lines changed and how those changes affect the surrounding code.\n\nCharacter-level diffs can become noisy very quickly, especially when formatting, indentation, or multiple small edits happen in the same line.\n\nThat is why line-level diffing is a good default for most developer workflows.\n\nBut Git still gives you more detailed options when you need them:\n\n```\ngit diff --word-diff\n```\n\nThis shows word-level changes inside modified lines.\n\nThe best algorithm is not always the most precise one. It is the one that gives the most useful output for the context.\n\n## LCS vs Myers: The Mental Model\n\n```\nLCS:    Find the longest part that stayed the same.\nMyers:  Find the shortest set of changes to get from old to new.\n```\n\nLCS gives you the intuition.\n\nMyers gives Git an efficient practical algorithm.\n\nWhen only insertions and deletions are allowed, these two views are mathematically connected:\n\n```\nedit distance = old length + new length - 2 × LCS length\n```\n\nSo:\n\n- If the LCS is long → fewer edits are needed\n- If the LCS is short → more edits are needed\n\nThey measure the same underlying change from different directions.\n\n## Why This Is a Great Example of DSA in Real Life\n\nMany beginners ask:\n\nWhere do we actually use DSA in real projects?\n\n`git diff`\n\nis one of the best answers — because every developer runs it daily without thinking about it.\n\nWhen you run `git diff`\n\n, you're using an algorithm.\n\nWhen you review a pull request on GitHub, you're using an algorithm.\n\nWhen you resolve merge conflicts, you're relying on algorithms that compare versions of files.\n\nThe algorithm is invisible behind a clean developer experience.\n\nThat's what good engineering looks like: the user sees red and green lines, and behind it is a carefully designed algorithmic solution built on decades of computer science research.\n\nThat's the beauty of DSA.\n\nNot just for interviews.\n\nInside the tools you use every day.\n\n## Practical Commands to Try\n\n```\n# Try different algorithms on any repo\ngit diff --diff-algorithm=myers\ngit diff --diff-algorithm=patience\ngit diff --diff-algorithm=histogram\ngit diff --diff-algorithm=minimal\n\n# Word-level diff, great for prose or config files\ngit diff --word-diff\n\n# Set histogram as your permanent default\ngit config --global diff.algorithm histogram\n```\n\n## Final Thoughts\n\nWhen you first learn LCS, it may look like just another dynamic programming problem.\n\nBut the core idea is powerful:\n\nFind what stayed the same so we can understand what changed.\n\nThat simple idea appears everywhere.\n\nGit uses related sequence-comparison ideas to show file changes. Code review tools use similar techniques to help developers understand pull requests. Merge tools use them to combine work from different branches. Document editors use them to show version history.\n\nSo the next time you run:\n\n```\ngit diff\n```\n\nremember that you are not just seeing red and green lines.\n\nYou are seeing dynamic programming intuition, graph search, and decades of algorithmic research — all compressed into one everyday developer command.", "url": "https://wpnews.pro/news/dsa-application-in-real-life-how-git-diff-works-lcs-intuition-myers-algorithm", "canonical_source": "https://dev.to/naimur_rahman_lam/dsa-application-in-real-life-how-git-diff-works-lcs-intuition-myers-algorithm-and-real-code-4ma2", "published_at": "2026-05-23 04:42:14+00:00", "updated_at": "2026-05-23 05:01:57.272515+00:00", "lang": "en", "topics": ["developer-tools", "open-source", "research"], "entities": ["Git", "Myers", "LCS"], "alternates": {"html": "https://wpnews.pro/news/dsa-application-in-real-life-how-git-diff-works-lcs-intuition-myers-algorithm", "markdown": "https://wpnews.pro/news/dsa-application-in-real-life-how-git-diff-works-lcs-intuition-myers-algorithm.md", "text": "https://wpnews.pro/news/dsa-application-in-real-life-how-git-diff-works-lcs-intuition-myers-algorithm.txt", "jsonld": "https://wpnews.pro/news/dsa-application-in-real-life-how-git-diff-works-lcs-intuition-myers-algorithm.jsonld"}}