Michael J Rubinsky <mrubinsk <at> horde.org>
2014-11-14 00:38:29 GMT
I've been slowly looking into options for development workflows after
splitting our repo. I'm convinced we should use git-subtree, but not
in the way I think others have suggested.
Gunnar has written an article detailing the use of git-subtree as a
way to keep BOTH the monolithic and split repos. There was a short
mailing list discussion to go along with thisa. I don't think that
this method will work; First of all, this will lead to two different
canonical Horde repositories for the same code. That's confusing.
Secondly, it is resource intensive. Gunnar's approach utilizes an
interim repository that will do the actual split filtering and
pushing, but it is s l o w. Third, and perhaps most important, is that
published topic branches won't be portable between the two.
Assume the monolithic repo is being used for development - it is
impossible to checkout a topic branch of one of the subtrees without
git rm'ing the folder, then re adding the subtree's topic branch via
git-subtree add. Even with squashing all the commits along the way,
this is *messy*. The monolithic's history will be polluted with at
least 2 merge commits everytime a branch is changed. Not to mention
that the state of the upstream monolithic repository will be
inconsistent. There is no telling what branch any of the subtrees are
currently on. E.g., if I replace framework/component with a topic
branch and the push the monolithic repository without replacing it
with master again, the next person who pulls will get a monolithic
repository with framework/component's code from the topic branch.
I propose that we only provide our individual repositories publicly.
Locally, however, we can utilize git-subtree to build a monolithic
repository we can develop against. This repository remains local and