0

I am trying retrospectively apply the principles of git flow to my repository.

I have all my releases tagged, and I would like to

  1. Create a new master branch
  2. Merge each tagged release into the new master branch as a squashed commit.

with the result being a master branch with a history containing only releases.

I tried to do the above, the first merge went as expected. And a diff confirmed that my master branch was identical to the tagged release. The second commit appeared to merge correctly, however a diff with the corresponding tagged release commit revealed many differences.

  1. What could account for the tagged release merge resulting in a commit that was different?

  2. How do I ensure the result of the merge is exactly the same as the tagged release commit?

Thanks

pingu
  • 8,719
  • 12
  • 50
  • 84

1 Answers1

1

It is not that surprising that when merging two release branches corresponding to different tags leads to a tree that is not an exact copy of that of one of the tags, because it is precisely a merge and the result depends on the history that leads to both tags.

So I guess that your question amounts to the need for command

git merge -s theirs branch-of-release

which doesn't exist, as explained in Git's doc of git merge:

[…] note that, unlike ours, there is no theirs merge strategy […]

Nevertheless, I found the following answer on SO that could be useful for your use case: git command for making one branch like another.

ErikMD
  • 13,377
  • 3
  • 35
  • 71