Menu
I have a file say a.java which I have modified.
In the meantime before I push my changes to master, Another developer deleted that file (basically renamed the package).
Now when I rebase my changes, I see
Unmerged paths:
deletedbyus: a.java
Now since I want to keep the changes,I made ..I tried git add a.java but it does not seem to work i still see
Unmerged path:
deltedbyus: a.java
If i do git rm or rm,the file will be staged but it will show as deleted thereby removing the file alltogether.
What should be correct way to restore the file with my changes intact.
462
So you get to resolve the conflict by either reintroducing the file in your branch (accepting its state from the commit you`re cherry-picking), or you get to confirm the file should really stay deleted... as already explained in previous messages.
For some conflict notifications, Git will include a "Deleted by us" or "Deleted by them" message next to a file. That means that you modified a file in one branch and deleted it in another. Git has no way of knowing if you want to delete the file or modify it, so you need to make the choice yourself.
The "added by us:" is telling you that "com/company/A. java" is new to your branch and was brought in by the branch you're rebasing against. But due to the way git implements rebase, "us" is really their branch. Not sure if this is counted as a rebase "merge conflict" unless you deleted "com/company/A.
Assuming you are on master branch, and someone else pushed the the package change of a.java file to master and you are now doing git rebase on master branch after committing your changes, let's clarify what it exactly means:
In this situation git is resetting the HEAD of your master branch to the one of the remote origin/master branch. And then git is taking each of actually your commits and rewriting them on top of the new master's HEAD.
Actually they are your commits which are being rewritten, but from git's point of view they are the changes of them because they belong to the branch git is rebasing on top of your current branch (which aren't actually your changes, but it's now our branch, therefore our changes).
In this context, when git tells you deletedbyus it means that in the commit git is rewriting, the file exists again, because it has been already deleted in our branch (by us), but what should I (git) do with the changes to a file that no longer exists? Someone deleted it intentionally and I (git) cannot create the file again without confirmation (and that is correct, indeed).
So, what should you do to fix this situation? Actually you should include your changes (theirs from git's point of view during the rebase) in the location where the file now exists (on the new package, assuming you want to keep the package change). Once you have done this, you should do
# Manually carry the changes you made to
# file/on/old/package/a.java
# to file/moved/to/new/package/a.java
git add file/moved/to/new/package/a.java # To confirm your changes
git rm file/on/old/package/a.java # To confirm deletion
git rebase --continue # To continue with your rebase
But, which changes did you make to the file? You can see it with git diff HEAD:file/moved/to/new/package/a.java file/on/old/package/a.java
130
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
