tags:

views:

121

answers:

3

Possibly related to http://stackoverflow.com/questions/286988/git-pulling-changes-from-clone-back-onto-the-master

I was working on an ASP.NET project when I discovered I needed to make an "experimental" set of changes which may or may not have been required in the production version.

The obvious thing to do was to create a branch.

However as I was familiar with darcs and svn but not git, I assumed that a clone was the "normal" way to create a branch (I now know that git branch would have been more appropriate.)

I continued to work on the experimental change in the clone and, at the same time, other changes in the original repository.

Since then I have discovered that the experimental changes are desirable in the production version and would like to merge the two change sets.

If I had originally done a branch instead of a clone, this would be trivial. I'm sure it's not too hard to merge between separate repositories, but having looked through the docs I don't think it can be done with a single command (a simple pull does not work.)

I haven't (yet) explicitly configured one repository as a "remote" of the other, but I am guessing this will be part of the solution.

The upstream repository at the time did not use any VCS - it was just a directory full of zips with version numbers appended to the file names.

So I would like to know:

  • What's the easiest way to merge the change sets across repositories? (I don't expect any major conflicts.)
  • Just how harmful is it to clone instead of branching? Have I lost any information by doing this, e.g. shared history, common dependencies?
+7  A: 

In your original "un-branched" git repository, run these commands:

git remote add name_it_anything /path/to/the/other/git/repository
git fetch name_it_anything
git merge name_it_anything/master

That will merge inn all the changes in nname_it_anything. If you don't want all of them, but just a selection of the commits, you can git log name_it_anything/master to see the list of commits and then git cherry-pick [SHA] for each of the commits you want to merge.

August Lilleaas
A: 

I think you can git-format-patch in one repository, and then apply in another. This way all important information is preserved.

phjr
+3  A: 

Regarding the second part of your question:

Just how harmful is it to clone instead of branching? Have I lost any information by doing this, e.g. shared history, common dependencies?

Git is a distributed version control system. The whole point of a DVCS is to be able to merge changes back and forth between different repositories.

Jörg W Mittag
Yes, but does it retain all the info about differences between repositories as it does about differences between branches? Or is there a greater risk of it failing to resolve conflicts?
finnw
it will import the other repository's commits, so yes, it will have proper information. as Jörg said, git was specifically made for this. People clone and merge all the time, see github.com for example
Maximiliano Guzman