By squash
ing the merge, you've created a commit which has the effect of, but is not really, a merge.
That is, the working tree has the modifications you'd expect, but the metadata doesn't: crucially, the commit doesn't have two parents (one on master
and one on alt
) and therefore subsequent merges can't figure out the last common ancestor.
Useful uses of squash
- merging a completely finished feature branch onto
master
. I'll accumulate any useful information into the squashed commit, but specifically don't want this feature's incremental development history polluting the master
commit timeline.
- merging several independent features (or contributions from different developers) onto the same integration branch, again without preserving their incremental histories. I could rebase them all together, and then use
rebase -i
to squash their commits, but this is easier
Useless uses of squash
Any merge where you want to keep the history and ancestry metadata intact, such as any time you want repeated recursive merges to work correctly, specifically what the OP is trying to do.
squash
just isn't really a good default, which is why it isn't the default.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…