git madness

[TheExDeus]

Maybe someone can help. In middle of August I made massive changes to GL3, so we could move forward with many features. Sadly, no one had the time to test it for the week I had it as a pull request. So after merging the whole thing broke. I reverted master to previous commit, so master would work again. I would really like that to be merged though. To do this I need to update the GL3.3Fixes branch (https://github.com/enigma-dev/enigma-dev/commits/GL3.3Fixes) to current master changes, and then test/fix everything that is still broken. I sadly don't know how to do it in git. I just tried this:

git checkout GL3.3Fixes
git merge master

But this just returns "everything is up to date" when it clearly isn't. I can try rebasing, but that can cause problems later. I think the issue here is that the revert commit in master (https://github.com/enigma-dev/enigma-dev/commit/07ac18577f5f8007ac6d5e3b5282edafdfeeed02) needs to be behind my branch (so when I merge with master it doesn't revert my changes), but at the same time any commit AFTER that revert, needs to be ON TOP of my branch. So how can I do it?

Basically I need the GL3.3Fix branch to be updated to the newest master, while still remaining in the GL3.3Fix branch. My fixes needs to be on top after the revert, but behind the other commits.

[Josh @ Dreamland]

I assume you committed an unfinished (or crappy) merge? Do a checkout to before you committed it (use git log to find it), git checkout -b SomeNewMergeBranch, then try git merge master again.

Otherwise, I misunderstand your problem. What state is master in, and what state is GL3.3Fix in?

[TheExDeus]

It happened like this:

git branch GL3.3Fix from master
git commit many changes
git checkout master
git merge GL3.3Fix
Find bugs
git revert GL3.3Fix

git push tons of stuff in master since then

and now I want:
git checkout GL3.3Fix //This is the one that was merged into master, but the branch remained, so I can still checkout it
git merge master //Pull all the changes that has been on master since
git commit fixes to GL3.3Fix

Then I will end in this (but probably via the merge button in GitHub):
git checkout master
git merge GL3.3Fix

I guess checkout the original commit and then create a branch from it could work. I wanted to use the still existing branch though (https://github.com/enigma-dev/enigma-dev/commits/GL3.3Fixes).

[TheExDeus]

Okay, so this is what I came up with: https://github.com/enigma-dev/enigma-dev/commits/GL3.3CleanUp
I did this:
git checkout 83dc5dcd6d7b788aa673e395489160fb27f0bcfb (which is the commit just before the revert commit)
git merge -s ours 07ac18577f5f8007ac6d5e3b5282edafdfeeed02 (here I basically skip the revert commit (choose my changes over the ones in revert), moving the HEAD forward)
git merge -s ours f969248d94c46f6d6b95e2dd4928f5def99d46b4 (here I skip the pull request for the revert, which in Git is another commit, again moving the HEAD forward)
git merge master (here I update the whole thing to newest master)

There was about 20 file conflict I had to fix.

It's by no means pretty, but is it "satisfactory"? Because I think there is no prettier way to do this. I will still have to pollute our git history anyway. For example, in that failed commit I added new glew, which is 30k lines, then I reverted those 30k lines, and now I added again those 30k lines. Is git smart enough to understand that, or is there 1.6mb delta's now?

edit: It somehow didn't merge complete master.... git is such a clusterfuck sometimes. I end wasting hours just to get thing work and then develop for 10 minutes. I'll continue trying. What I learned from this experiance is this - NEVER use git revert function. Leave the master broken if you must, and the fix it there. Never for anything that is holy do it. You won't be able to revert that revert.

edit2: For some reason CompileSource files are totally different in master than they are in GL3.3CleanUp, while they shouldn't be. It leads me to believe the other files might be in the same situation, and thus I will probably revert tons of changes if I ever pushed that into master. So sadly I have failed. Any ideas on how to uncluster this f***?

I will try to explain as plain as possible (it's very hard to explain stuff in git, it's not meant to be easy). Imagine this tree (http://pastebin.com/b28HWZfi):

Code: [Select]

master -- commit a -- commit b -- more commits ------------------------------------------ revert d -- commit e -- commit f --
                            |                                     | merge d into master                                                                             |
GL3.3Fixes branch     \ commit c -- commit d --- /                                                                                                          \ GL3.3Fixes branch with master changesI want the "GL3.3Fixes branch with master changes".
Until this gets fixed I cannot do anything. There is a GUI extension I wanted to finish that I started months ago. But it got frozen because of this.

edit3: Nevermind, it's impossible to draw trees in this forum for some reason. Check here: http://pastebin.com/b28HWZfi

[Goombert]

Well, first, don't worry about the history Harri, it's already gone to shit for the most part several times in fact. This happens to be why I get very anxious about leaving pull requests setting around, they can and will become a nightmare after a while.

[Josh @ Dreamland]

Harri, I think it'd be easier to help you if you stopped in on the IRC. Is your branch up on Git? I can merge it for you if it is.

[TheExDeus]

Well, i'm fearing more about the bloat the whole thing will get. Of course deltas are compressed, and text compresses well, so it is a lot smaller. Anyway, I finally did what I wanted using revert of a revert. So I reverted the commit that reverted the first commit. I ended up with much less conflicts this way (only 3 files) and everything else seems to work fine. Now I just need to fix the original problems.