tags:

views:

86

answers:

2

I have a large project that I was upgrading to edge Rails. I made a copy of the entire project directory and refactored there as a precaution to trusting git (or at least how I might use/misuse it). After completing most of the work I returned to the original project directory and at the console (this is from memory and so is loosely based on what actually happened):

git branch edge
git checkout edge
git rm vendor/plugins
git commit -m "wiped out old plugins"

then I manually copied in the latest versions of the plugins which I had updated in my copied project.

git add vendor/plugins
git commit -m "re-added in plugins, some unchanged, some later versions"

My understanding is that the above add is recursive. To gain some trust in git I swapped back and forth between the master branch and the edge branch at various times during my work, just to make sure it was handling swapping okay.

git checkout master
git checkout edge

What I noticed is that (after some swaps) in the edge branch some of the plugins reverted to the master versions. Numerous times I attempted to commit the lastest version of the problematic plugin, but it eventually reverted after swapping.

I suspect that there might have been an issue with the way I added the files after manually moving them over. (Was git add vendor/plugins/* necessary?) Has anyone had any issue with swapping between branches when two branches contain some of the same subdirectories? How might you handle the merging of the changes found in a copy of the app found in one directory back into the original? The original respository is clean, whereas the copy is fairly messed up from having attempted to get certain plugins to remain changed in the edge branch.

+5  A: 

That seems like a really strange way to do what you intended.

The more "git" way of doing what you proposed would have been to:

$ git checkout -b edge
... #make your modifications for the port.
$ git commit -m'ported plugins to rails edge' -a
$ git checkout master # original code is there untouched
$ git checkout edge # ported code is there just as you commited it.

From there depending on what you're goal is you can:

$ git checkout master # make sure you are on the master branch
$ git merge edge # merge the edge branch into master
... # fix any errors
$ git branch -d edge # remove the edge branch since you don't need it anymore.

Or maintain two branches. One ported to edge, the other the unported. This is probably not what you want. Branches in git are cheap and easy and is perfectly acceptable to throw them away when you are done.

Jeremy Wall
I appreciate the feedback. I knew I wasn't taking a git-standard approach, but I am still a git novice and so wanted to be careful in case I might execute a git command I didn't wholly understand and lose a bunch of work.
Mario
Since the branches are cheap/easy/and safe as long as you branch first then you can throw away anything you do on the new branch without worrying about messing up the master branch.
Jeremy Wall
Unfortunately, even following your steps I get this kind of issue when I attempt to switch back to the master branch: error: Untracked working tree file 'vendor/extensions/blog_tags/LICENSE' would be overwritten by merge.I had experienced this before and it seems to cause trouble.
Mario
+2  A: 

git checkout will not remove files not in a commit. you have to use git clean -f to remove all unwanted files in the current working directory. you could also just remove the folder and git checkout -f again.

other than that it’s really better to create a branch for working on your edge features and then merge the branch back, like mentioned by jeremy wall

knittl