13

I have two local branches master and dev. Both branches contained three folders:

projectBeta
project
project_v1

I wanted to just keep projectBeta and remove project and project_v1 and then rename projectBeta as project. So that's what I did separately on both branches, committing as I went along. All looked good until I tried to then merge the dev branch to master, and I got a pile of these kinds of errors:

CONFLICT (rename/delete): Rename projectBeta/test.c->project/test.c in dev and deleted in HEAD
CONFLICT (rename/delete): Rename project_v1/test.c->project/test.c in HEAD and deleted in dev

So it looks like Git tracked the renames in different ways in the different branches.

If I do a git status, I get

# On branch master
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   added by us:        project/test.c
#
no changes added to commit (use "git add" and/or "git commit -a")

First thing I don't understand is why the status just says that it's "added by us" when the merge report says it's renamed and deleted by both us and them?

Secondly, I want to use the dev branch version (them) of test.c, but now when I try

git co --theirs project/test.c

I get

error: path 'project/test.c' does not have their version

...so I don't know how to ensure the merge will use the content from the dev branch?

Finally, is there a best-practice way to avoid such a mess like this in the future? Basically, changing folder structures independently in branches where the content is not ready to merge first...

SubG
  • 740
  • 1
  • 7
  • 14
  • I don't know your intentions for doing so, but my guess is that when you created the projectBeta and project_v1 directories, you should have instead been creating a new branch and continuing to work in the project directory. That project directory may even be better off in a repository of it's own, depending on how you are working. – Gerry Sep 01 '11 at 00:29
  • Yes, that structure dates from pre-Git times. My rename/deleting action above was intended to make it align with the Git way of working. However, I still have more branches with this obsolete structure and can't see how to avoid these conflict errors when streamlining them before merging. – SubG Sep 01 '11 at 06:49
  • 1
    "I wanted to just keep projectBeta and remove project and project_v1 and then rename projectBeta as project. So that's what I did separately on both branches" Well for a start you shouldn't really do that. You should do it on one branch and then merge the change into the second branch. – Gerry Sep 01 '11 at 11:12
  • 1
    Ah... *dawning realisation* yes, that sounds like the proper way to go about it. I'll give that a go with some other branches. Thanks. – SubG Sep 02 '11 at 14:18

2 Answers2

2

try this

git pull

go to folder to delete project and project_v1, rename projectBeta to project.

git add --all
git commit 
git push

and you do the same for other branch

2

What you need is git mv and git rm.

My guess is you probably rm'd the directories without letting git know. You must let git know because it keeps track of all the folders and needs to know how to deal with them correctly.

What you should do is:

git rm -r project
git rm -r project_v1
git mv projectBeta project
jtsao22
  • 1,962
  • 1
  • 13
  • 13
  • From reading up on git mv, I thought that these explicit git commands were not needed (e.g. http://stackoverflow.com/questions/1094269/whats-the-purpose-of-git-mv) and by adding and committing as I went along that git would track it correctly without needing an explicit rm and mv. – SubG Sep 04 '11 at 21:44
  • 1
    Git in the end needs some way of tracking changes. As you can see by the first person who responded to that question, a git add and git rm are run. Both still give git a way to track whats going on. The 3rd answer is true too, but when they say "The effect is indistinguishable from removing the file and adding another with different name and the same content," I believe they mean with git commands. – jtsao22 Sep 05 '11 at 01:58