0

Sorry for the long title, but this is a very specific question. Let me describe it better.

I am working in a branch, let's call it new-feature. I change some code, and I also add a new file. I merge or rebase from a branch that gets frequent updates:

git rebase develop

Afterwards, I only have one file in conflict. I examine the file with git mergetool, and find that I only want upstream's code, so I discard my changes. But I have also added new files of my own, which of course had no conflict with develop.

  • I cannot git rebase --continue, because now that I've accepted upstream develop's version of the file, git thinks there is no change worthy of git add-ing.
  • If I attempt git rebase --skip, it seems I'll lose my newly added file(s).

I may not have captured all the nuances as this happened across several commits, not one. Specifically, it seems that I should be able to git rebase --continue due to the new file. I'm honestly not sure. Let me know if you think I've made some wrong assumption in trying to simplify the problem here.

Has anyone else run into something like this, and solved it? I'm looking for the most effient solution.

moodboom
  • 6,225
  • 2
  • 41
  • 45
  • 1
    You *should be able* to `git rebase --continue` if the commit you've just copied adds that file. The only time `git rebase --skip` is needed is if the commit you've just copied has *no effect at all*. `git status`, after resolving the conflict, should show the added file as a new file (not as an untracked file), as the creation of the new file was not part of a conflict and hence was already done. The mergetool code only bothers with the unresolved conflicts. – torek Jan 22 '21 at 00:14
  • 1
    Note that if you have a series of commits: *add file A* (commit) *modify file B* (commit) *modify file C* (commit), and you then rebase this series—copying each commit one at a time—and the *second* commit has a conflict that, when resolved, "empties it out" as it were, that's when `git rebase --skip` is useful. This skips the "modify file B" one and goes on to the "modify file C" one. The end result of the rebase would be that you would have two commits instead of three. – torek Jan 22 '21 at 00:16
  • Thanks @torek I guess I'll chalk it up to a more complicated set of commit merges, not sure where it went wrong. Appreciate the comments! – moodboom Jan 22 '21 at 02:07

0 Answers0