Reading conflict markers in Git - Time & Space Complexity
When Git finds conflicting changes during a merge, it adds conflict markers in files. We want to understand how the time to read these markers grows as the file size grows.
How does the work to find and read conflict markers change when the file gets bigger?
Analyze the time complexity of reading conflict markers in a file.
<<<<<<< HEAD
code from current branch
=======
code from incoming branch
>>>>>>> feature-branch
// Git scans the file line by line to find these markers
This snippet shows the conflict markers Git inserts. Git reads the file line by line to detect these markers.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Reading each line of the file sequentially.
- How many times: Once for every line in the file, from start to end.
As the file gets longer, Git reads more lines to find conflict markers.
| Input Size (n lines) | Approx. Operations (lines read) |
|---|---|
| 10 | 10 |
| 100 | 100 |
| 1000 | 1000 |
Pattern observation: The number of operations grows directly with the number of lines. Double the lines, double the work.
Time Complexity: O(n)
This means the time to read conflict markers grows in a straight line with the file size.
[X] Wrong: "Git only reads the conflict markers, so time is constant no matter the file size."
[OK] Correct: Git must scan every line to find where conflict markers start and end, so it reads the whole file, not just the markers.
Understanding how tools like Git scan files helps you think about efficiency in real tasks. It shows how simple line-by-line reading scales with file size, a useful skill for many coding and DevOps problems.
"What if Git used an index to jump directly to conflict markers? How would the time complexity change?"