In one of the previous posts, I described the Git procedure used to split files with preserving history. I also mentioned that if this procedure is used with a branching strategy where feature branches are squash-merged to main branches, it won’t work. History will be gone no matter how we’d split the file.
This post is a short appendix with the comparison of the three methods of splitting files proposed by Raymond Chen. I examined all of them against a number of commits needed to correctly split the files and posted results here.
This time I don’t use a custom class as an example, but I’m just exactly following the procedure described by Raymond and showing the results.
Base method
Described here
Hard way with commit-tree
Described here
Easy way with misleading commits
Described here
Results
As we can see, these three ways differ not so much. Most neat is the hard way, but it requires “plumbing”, which means that cannot be done via GUI tools and command-line + experience is needed. In turn, we get the smallest number of commits. The base method adds two more commits, “easy” method one additional commit.
My opinion is that if no special requirements are present, one should stick to the “easy method with misleading commits”. It’s a good tradeoff in terms of complexity and numbers of additional commits. Only experienced users should choose the most difficult procedure.
