What is the value of actually merging the Yii branch into master? Isn't
another option to re-name the master branch "1.92", and rename the Yii
branch "2.0", and instructing people to commit to the 2.0 branch instead of
The reason I ask is I'm trying to picture how debugging might be affected
after such a merge:
(1) In many cases, we have identical commit messages for Yii and master.
Will it be easy to search the logs for the Yii vs. 1.92 commits for a
particular bug and checkout the right code (e.g. the version right before
that fix)? I guess it will be obvious if we've checked out Yii instead of
1.92 (since the code organization is different), but that sounds like a it
of a pain and trial and error to get the right version, especially if you
need to step back through several code iterations
(2) Would that affect the ability to use the git commands that let you find
the source of an error (the ones where you write a test case, and you tell
git that the error happened sometimes in the last 6 months, and it
iteratively checks out code, runs the test, and keeps splitting the
difference until it finds the earliest code where the test fails)?
(3) If we found we needed to make a high priority fix to 1.92 and to 2.0,
would that be harder after merging the 1.92 and Yii branches? Seems you'd
need to checkout the final 1.92 branch, make the changes - but then commit
them to which branch? At that point, committing to master wouldn't make
sense, since master would be based upon Yii, so you'd need to maintain a
newly created 1.92plus branch for the critical fix, in which case, why
bother merging Yii into 1.92 in the first place.
So, I'm not convinced that merging Yii into master gains us anything; and
it seems to risk making maintenance considerably harder.
Instead, can we just rename the branches and/or simply instruct authors to
only commit to the 2.x branches?