Making sure git pull (fetch+merge) doesn't screw up ?

[xeross155]

Hey,

I've had this a few times now, after a few times of pulling and pushing one of my branches it suddenly stops working. All I can think that of that can cause this is that there's something going wrong when merging, isn't it possible to have an interactive merge like "git add -p" ?

~Xeross

[freghar]

"suddenly stops working" is a poor definition of an error. I don't know any interactive merge tool as it would effectively eliminate the merging mechanisms with more than 2 branches, but if you just want to merge changes from those two, you can as well apply a diff of those branches and then "git add -p" it.

[xeross155]

Well an example is that character creation stopped working with mangchat after a few pulls from the mangos master. But I guess I probably messed up my merge conflict resolve now I think of it.

[freghar]

Well, you _can_ revert a merge. It's a bit problematic though. The "problem" lies in git's history tracking part of the merging algorithm - see http://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt .

Simply said, when you merge something and use a "recursive" merge algorithm (2 branches), git looks up the last "common ancestor" of both branches and start doing resolutions from that point (rather than using the project's whole history). Revert is a normal commit. It has no special flags, nor anything fancy, it's _just_ a normal plain commit with reverse changes applied. That means the second merge will think you want to merge only the changes made (on the second branch) from the first merge, not everything again. But you reverted them and since revert is a regular commit, you'll get a lot of conflicts, because you're missing the changes merged (and "silently" reverted) earlier.

I'm not able to make an ascii art here, so http://paste2.org/p/591967 -- when you do the first merge (M), everything's okay (from the technical point of view). Say the developer did some fixing in G, H, I and he wants you to pull those changes (N). Git simply takes only those commits into consideration, none of the previous ones are merged. And if you revert the merge (_changes_ made by the merge) somewhere between M and N, ...

[xeross155]

Just a quick heads-up that might help some people (Even though this is an old thread).

What I now do when I want to make sure my code stays the same is create a branch based on the current one, and rebase it with master. after that switch to the current main one and merge it with master. After that I compare the 2 for any problematic differences.

[VladimirMangos]

you can do more easy.

Just remember current hash value and do operation

then you if have problems just do: git rebase --hard savedhash

and branch state will return to old state. hash not only store related code changes but also hold all history attached to hash commit as head

[Schmoozerd]

I personally prefer to keep the "master" brunch clear, and always work in different branches, in this way, I always can merge master to my dev-branch(es), and see conflicts, and abort if needed

[xeross155]

@Schmoozerd: Hmm if you want a clean branch you'll have origin/master so you don't really need the local clean master. Though that statement is a bit irrelevant.

[xeross155]

That his is still on the first page after all that time.

Anyway, from what I've found the best approach for me to keep my work not-broken and easily manageable is to rebase it every time, thought this might not be desirable for public projects that people pull from, unless you only supply them with patches that is.