0

If the dirty files are all files not impacted by the rebase, then it seems fairly easy to tolerate that. Why is git so strict?

jhourback
  • 4,381
  • 4
  • 26
  • 31
  • Have a look at [this question](https://stackoverflow.com/q/4913360/9210961) and its answers. – prosoitos Oct 16 '20 at 00:22
  • Conflicts are not the only case. Is `git add --all` useful when rebasing interactively? I believe it is, unless your working directory has files you wouldn't like to spoil your history. – terrorrussia-keeps-killing Oct 16 '20 at 06:45

1 Answers1

2

In addition to the answers here, consider what would happen if there was a conflict. Normally you get the changes which were successfully merged staged, and the conflicted files unstaged. You then fix the conflicts, stage them, and continue. If anything is left unstaged, Git will prevent you from continuing.

$ git status
interactive rebase in progress; onto 84847db1
Last command done (1 command done):
   pick acc8ef41 Feature: Use the 'google-cloud-bigquery' gem.
Next commands to do (9 remaining commands):
   pick cd88f633 Feature: Add methods to locate a BigQuery dataset table.
   pick 5a600a5b Feature: Something something.
  (use "git rebase --edit-todo" to view and edit)
You are currently rebasing branch 'issue/#1812' on '84847db1'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   Gemfile
    modified:   Gemfile.lock
    new file:   app/lib/google_big_query/client.rb
    new file:   spec/factories/google_big_query.rb

Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
    both modified:   config/credentials.yml.enc

If the working area is dirty those dirty changes would get mixed up the changes as a result of the rebase. You would not be able to tell what was part of the rebase and what was dirty. Even if you were, it would be all too easy to git add a dirty file and inject unrelated changes into the rebase.

Let's say you had changes to Gemfile when you started the rebase, what would Git do in the situation above? Throwing out the dirty changes would be the worst option, Git does not want to throw out your work. Git would have to abort the rebase, or pause and get you clean up the directory.

Instead, git stash your changes before rebasing and restore them after.

Schwern
  • 153,029
  • 25
  • 195
  • 336