CODEWITHSUNDEEP
gitgit-squash
Nickpick
Nickpick

Reputation: 6597

Would merge --squash cause conflicts with cherry picks already in develop

We are using the git flow model merge feature branches into the develop branch via pull request, after theyhave been rebased onto develop.

Sometimes one feature branch cherry picks from another one, and one of them will be merged into develop first. When the second one then rebases onto develop, those cherry picks are fast forwarded.

My question: currenty we just use merge (which could easy be replaced with --ff-only I assume as we always rebase), but could we alsod o --squash --ff-only? Would that then cause conflicts when the cherry picked commits are rebased onto develop when those commits are already in there?

The reason why I fear additional conflicts would arise is as follows: Let's assume both commit1 and commit2 make changes in one file. If they are merged into develop and then the second branch that cherry picked them makes a rebase, it would recognise that those two commits are already in there.

In case those two commits are squashed and it tries to rebase on top of it, it would no longer see that and when replaying the first commit on top of the rebase would already contain the commit2 and thus cause a conflict.

feat1: ... A -- B 
feat2  ... A (cherry picked) -- B (cherry picked)

feat1 is merged with squash into develop

develop .... S

Would rebasing feat2 onto develop cause a conflict if both A and B edit the same file?

Upvotes: 0

Views: 479

Answers (1)

Mark Adelsberger
Mark Adelsberger

Reputation: 45819

Absolutely squashing the commits would thwart patch ID detection, so that rebase could no longer protect you from conflicts arising from the cherry picked commits. (And conversely, if the commit sequence makes and reverts changes, then potential conflicts could be eliminated by squashing - but that's more of an aside.)

Upvotes: 1

Related Questions