Well yes, but the changes they introduce would not undo other changes.
If I look at the "symmetric" difference of the parents of our current
master merge, I see
git log --stat --graph --source --date-order 744709d...ab45be2
[...]
That all looks normalized. The duplicate commits are weeded out, and we
have the two starting merges (starting from the same two commits)
| * commit 17183f4a9696f2187128490a669895964959fa84 ab45be2
| Merge: caa20be feb3b8d
| Author: Francisco Vila<address@hidden>
| Date: Thu Mar 1 15:38:35 2012 +0100
|
| Merge branch 'master' into lilypond/translation
and
* commit e885a8cabc8335f1c46c48e92d4048e9d258cd10 744709d...ab45be2
Merge: feb3b8d caa20be
Author: Francisco Vila<address@hidden>
Date: Thu Mar 1 13:59:42 2012 +0100
Merge branch 'lilypond/translation' into staging
If we look at their difference, we see that while they start from the
exact same two parent commits (just in a different order), they arrive
at staggeringly different results:
git diff --stat 17183f4a9696f2187128490a669895964959fa84
e885a8cabc8335f1c46c48e92d4048e9d258cd10
[...]
49 files changed, 549 insertions(+), 448 deletions(-)
It turns out that 17183f is not actually a merge regarding the trees.
Instead it is an exact copy of caa20be. That is something that happens
when specifying a non-standard merge strategy. Or there was something
else that went wrong that made git think that caa20be was everything
that it needed.
So
| * commit 17183f4a9696f2187128490a669895964959fa84 ab45be2
| Merge: caa20be feb3b8d
| Author: Francisco Vila<address@hidden>
| Date: Thu Mar 1 15:38:35 2012 +0100
|
| Merge branch 'master' into lilypond/translation
_thinks_ it merged master (feb3b8d at that point of time) into the
translation tree and tells git that it did so. The other merge commit
claims the same, and git reconciles those conflicting claims in a manner
that wreaks havoc. I'll see whether I can get this fixed up. The
problem is that we can't just revert the last merge we have at master:
that essentially dials everything back to the state before the merge,
except that git keeps thinking that everything that should ever come
from the translation branch has already arrived, and will not
reintegrate it next time.