0

I want to edit a file in a commit(not HEAD). I read this answer, when I do it, I meet a conflict in the commit after that commit. I wonder will the file in all the commits after that commit be modified, which means a lot of conflicts.

Tokubara
  • 392
  • 3
  • 13
  • It should be possible to just resolve the conflict in and modify the next commit, then it should stay fixed, unless it also conflicts with subsequent commits. Did you try that? – underscore_d May 07 '21 at 09:43
  • Not all of the commits. Only the ones that are rebased – evolutionxbox May 07 '21 at 09:44
  • So I just need to resolve the conflict only for the next subsequent commit , not all subsequent commit? – Tokubara May 07 '21 at 09:48
  • @Tokubara: the exact set of conflicts, and when and how they recur, depends on the exact set of original commits and the changes you make as you go. We cannot predict them unless you show us all the commits (including the new ones you will make!). – torek May 07 '21 at 09:49

1 Answers1

0

Technically, you are not modifying any files in any commits. Instead, you are taking older commits, using them to extract and update a working tree, and using the resulting working tree files to generate new (and presumably improved) commits that you will use instead of the older commits.

Whenever you do this, there is a chance that cherry-picking one of the older commits—rebase is essentially a series of cherry-pick operations—will result in a merge conflict. If that happens, you must resolve the merge conflict. Git cannot do it for you: if it could, it would not have produced a merge conflict in the first place. A merge conflict occurs when "you" and "they" make incompatible changes to the same line, or make changes that abut in a way that Git cannot resolve on its own. The peculiar feature of rebase is that "you" and "they" are often the same person, and the notions of --ours and --theirs, useful during other merge conflicts, become somewhat nonsensical.

torek
  • 448,244
  • 59
  • 642
  • 775