how to avoid conflict when I want to remove all files from git repo and then add new files

Question

(Editing the question :)

I have 2 repository in github, These repositories are http://github.com/abc.git and http://github.com/xyz.git.

Now the repository "abc.git" was the main repo for the project. After about a month of development we found we could do better by making re-useable code. So we decided to create a new repo for a - reusable generic code base i.e. xyz.git. So now we have

1. abc.git (very project specific code + external module + code "that we want to re-write")
2. xyz.git (code "we made re-useable" + external module)

Now code that we made re-useable is basically we added some new files, delete some old files and modified in xyz.git. This code originally comes from the code "we want to re-write" from abc.git.

So far so good I hope :)

Now we have 2 options

1. create a new repo say project.git, add a new remote repo i.e. xyz.git and merge and pick the files we need from abc.git. So in terms of commands the following

   • the whole github new repo creation process and add a README file. (this is my project.git origin)
   • git remote add xyz git@github.com:xyz.git
   • git checkout -b xyz
   • git pull xyz master
   • git status
   • git checkout master
   • git merge xyz
   • git commit -a
   • git push origin master

Now we have project.git populated with xyz.git + README and start the hard work of cherry picking files from abc.git (which I want to avoid also I miss out on all the old history)

2. What I thought I could do is delete all the files from abc.git and bring back the xyz.git. In terms of code in the following manner.

   • git rm -r * (this is on my abc.git origin)
   • git commit -m

   • git push origin master (now abc.git has no files but it has .gitmodules and .git)

   • git remote add xyz git@github.com:xyz.git

   • git checkout -b xyz
   • git pull xyz master

This is where the conflict starts.. there are 2 types of conflict (external modules, because of some common external modules and some files).

I have thought about a third option which is to just do a git log -l and dump it to a text file and use some viewer to get the history.

Frankly I just want to save the history best possible way possible, cherry picking is boring but it's do-able. Another question is how to save repo logs if you need to delete a repo? Only reason I want to keep a defunct repo alive is for the history and changes.

Thanks.

Answer 1

I'm totally guessing because it's hard to tell exactly what you are doing from your question. But my guess is that your remove conflicts with the remote repo's change history. A line gets modified in the remote and deleted in yours. Git doesn't know what to do so it marks it as a conflict.

I think your question would be easier to answer if we knew what your goal was.

Answer 2

Your edit made it better, but it's stil hard to know just what you want to do. For example: it's still unclear to me why you want to cherry-pick if xyz is a working (fully functional) evolution over abc.

If what you want is merge the two repositories so no history is lost, well... just do it. You can have two independent branches live there without any stamping on the other's feet. For example (taking these two because they're on top of github's repo page):

$ git clone git://github.com/rails/rails.git monster
$ cd monster
$ git fetch git://github.com/madrobby/scriptaculous.git master:old
$ git branch
    * master
      old
$ ls
    [ looks like rails ]
$ git checkout old
$ ls
    [ looks like scriptaculous ]
$ git checkout master
    [ looks like rails again ]

If what you want is merge the history baselines, i.e. make xyz a descendent of abc, it's specifically documented in the git filter-branch manual page (search for --parent-filter), you just want to use your abc "old" branch as a graft point.

Talking about graft points, it looks like they might be used directly to do this, but I'm unfamiliar with the concept. Take a look at this discussion for more details.