Menu
Running into an issue that I've never seen while rebasing.
I have a master branch that has had some bugfixes.
I have a dev branch that forked off of master sometime in the past, before bugfixes.
I change to the dev branch, then run:
git rebase master
It rewinds and tries to replay the dev changes.
The rebase stops, I get a conflict that I have to resolve.
I resolved a normal conflict, added the resolved file, then run:
git rebase --continue
There is another conflict, and I run:
git status
..to see the state of things. I see some normal changes, some unmerged paths, but then also some Untracked files that I've never seen before:
path/to/something/existingFileName.ext~HEAD
I can look back and see that these files did not exist in either branch at the time of the commit that we reverted to. I'm curious about why they were created by the rebase process, and what, if anything I should do with them?
797
But during the rebase, HEAD is either their branch-tip (commit L ), or one of the new commits copied and appended past their branch-tip; and --ours means the branch being grown at the end of L while --theirs means the commit being copied-from ( G or H above).
Introducing errors is extra problematic when it happens during rebasing. This way, new errors are introduced when you rewrite history, and they may disguise genuine bugs that were introduced when history was first written.
These are the files it uses to reconcile the merge: yours, theirs, and the thing we both started with. After you resolve the conflict, and run git rebase --continue and get done, are they still there?
134
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
