Bird
Raised Fist0
Gitdevops~5 mins

Clean vs dirty working directory in Git - Performance Comparison

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Time Complexity: Clean vs dirty working directory
O(n)
Understanding Time Complexity

When working with Git, it is important to understand how checking the state of your files affects performance.

We want to know how the time to check if your working directory is clean or dirty grows as the number of files changes.

Scenario Under Consideration

Analyze the time complexity of the following Git command.

git status --short

This command lists all files that have changes not yet committed, showing if the working directory is clean or dirty.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

  • Primary operation: Git checks each file in the working directory to see if it has changed.
  • How many times: Once for every file in the project.
How Execution Grows With Input

As the number of files increases, Git must check more files, so the time grows proportionally.

Input Size (n)Approx. Operations
10Checks 10 files
100Checks 100 files
1000Checks 1000 files

Pattern observation: The time to check grows linearly with the number of files.

Final Time Complexity

Time Complexity: O(n)

This means the time to check if the working directory is clean or dirty grows directly with the number of files.

Common Mistake

[X] Wrong: "Git status runs instantly no matter how many files there are."

[OK] Correct: Git must check each file to detect changes, so more files mean more work and longer time.

Interview Connect

Understanding how Git commands scale with project size shows you grasp practical performance considerations in real projects.

Self-Check

"What if Git used a cache to track changes instead of checking all files every time? How would the time complexity change?"

Practice

(1/5)
1. What does it mean when your Git working directory is described as clean?
easy
A. There are conflicts from a merge.
B. There are untracked files present.
C. There are changes staged but not committed.
D. There are no changes to commit; all files are saved in Git.

Solution

  1. Step 1: Understand the meaning of a clean working directory

    A clean working directory means no changes are pending to be committed or staged.
  2. Step 2: Compare with other states

    Untracked files, staged changes, or conflicts mean the directory is dirty, not clean.
  3. Final Answer:

    There are no changes to commit; all files are saved in Git. -> Option D
  4. Quick Check:

    Clean working directory = no uncommitted changes [OK]
Hint: Clean means no changes to commit or stage [OK]
Common Mistakes:
  • Confusing staged changes with clean state
  • Thinking untracked files mean clean
  • Assuming conflicts mean clean
2. Which Git command correctly shows the current state of your working directory?
easy
A. git push origin main
B. git commit -m "status"
C. git status
D. git checkout

Solution

  1. Step 1: Identify the command to check working directory state

    The command git status shows staged, unstaged, and untracked changes.
  2. Step 2: Eliminate other commands

    git commit saves changes, git push uploads commits, git checkout switches branches or files.
  3. Final Answer:

    git status -> Option C
  4. Quick Check:

    Check working directory state = git status [OK]
Hint: Use 'git status' to see working directory changes [OK]
Common Mistakes:
  • Using git commit to check status
  • Confusing git push with status check
  • Using git checkout incorrectly
3. You run git status and see:
Changes not staged for commit:
modified: app.js

What is the state of your working directory?
medium
A. Dirty working directory with unstaged changes
B. Dirty working directory with staged changes
C. Clean working directory
D. Detached HEAD state

Solution

  1. Step 1: Interpret the git status output

    The message "Changes not staged for commit" means files are modified but not added to staging.
  2. Step 2: Determine working directory state

    Unstaged changes mean the directory is dirty, not clean, and changes are not staged.
  3. Final Answer:

    Dirty working directory with unstaged changes -> Option A
  4. Quick Check:

    Unstaged changes = dirty directory [OK]
Hint: Unstaged changes mean dirty directory [OK]
Common Mistakes:
  • Confusing unstaged with staged changes
  • Assuming clean when files are modified
  • Mixing detached HEAD with working directory state
4. You see this output after running git status:
On branch main
Changes to be committed:
modified: index.html

But you want to check if your working directory is clean. What should you do?
medium
A. Run git reset HEAD index.html to unstage changes
B. Run git commit to save changes
C. Run git add index.html again
D. Run git checkout index.html to stage changes

Solution

  1. Step 1: Understand the meaning of staged changes

    "Changes to be committed" means files are staged but not committed, so directory is dirty.
  2. Step 2: Unstage changes to check clean state

    Running git reset HEAD index.html unstages the file, showing if working directory has unstaged changes.
  3. Final Answer:

    Run git reset HEAD index.html to unstage changes -> Option A
  4. Quick Check:

    Unstage changes to check clean state [OK]
Hint: Unstage files with git reset HEAD to check clean state [OK]
Common Mistakes:
  • Adding files again instead of unstaging
  • Committing without checking unstaged changes
  • Using git checkout to stage files (wrong)
5. You modified two files: app.py and README.md. You staged app.py but not README.md. What will git status show?
hard
A. No changes to commit, working directory clean
B. Changes to be committed: app.py; Changes not staged for commit: README.md
C. Changes not staged for commit: app.py and README.md
D. Untracked files: app.py and README.md

Solution

  1. Step 1: Identify staged and unstaged files

    app.py is staged, so it appears under "Changes to be committed".
  2. Step 2: Identify unstaged files

    README.md is modified but not staged, so it appears under "Changes not staged for commit".
  3. Final Answer:

    Changes to be committed: app.py; Changes not staged for commit: README.md -> Option B
  4. Quick Check:

    Staged vs unstaged files shown separately [OK]
Hint: Staged files show as 'to be committed', unstaged as 'not staged' [OK]
Common Mistakes:
  • Assuming all modified files are staged
  • Confusing untracked with modified files
  • Thinking working directory is clean with staged changes