views:

81

answers:

1

This is how gitk currently looks in one of our projects:

https://dl.dropbox.com/u/2582508/gitk.png

This apparently, from all we can tell, happened after a single "git merge" was done with a remote branch - we're not sure why or what is going on. Any idea what happened here?

More importantly, what's the best way to fix it? Those merge commits are empty, but when doing "git rebase -i" merge commits generally don't seem to appear.

Most importantly, I would prefer to not make the history incompatible with other clones, i.e. they should still able to pull/push/merge with it. Is that even possible?

+2  A: 
Pat Notz
Thanks for your answer. However, I either don't understand it, or I wasn't clear in my question. I understand merge commits, and I'm fine to have them in the central repo - I don't think we want to use rebase here. But in the screenshot above I have smth. like 30 subsequent merges, each with two parents: the direct previous merge, and one in a series of older commits. There weren't 30 develop-merge-develop steps. And while I find it difficult understanding these kinds of trees, the merges also seem unnecessary to me. A single one (or few) could have accomplished the goal you describe.
miracle2k