Split Git
Michael J Rubinsky <[email protected]>
| Newsgroups | gmane.comp.horde.devel |
|---|---|
| Message-ID | <20141113193829.Horde.4XQ-LOkoAtNtK_4aYKkEsg1@h4.theupstairsroom.com> |
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 is not expected to match the state of any other local repository. This allows us to continue developing with more-or-less the same workflow we utilize now, and utilizing things like our framework_install script (mostly) unchanged. The components script will probably need to be tweaked, since we will obviously be releasing from the discrete repositories. Dealing with branch changes will still be messy, but the mess will be confined to the local repository and not pushed up to any public monolithic repository. Of course, helper scripts can be used to lessen the burden of things like changing branches, and split/pushing back to the upstream repositories. I've been cobbling together some ideas in a utility script locally that, among other things, can be used to setup the initial local repository. Thoughts? I'm sure I'm not the only one who wants to get this moving. Among other reasons, I don't want to work on any BC breaking code until we have this sorted and working. -- mike The Horde Project http://www.horde.org https://www.facebook.com/hordeproject https://www.twitter.com/hordeproject -- dev mailing list Frequently Asked Questions: http://wiki.horde.org/FAQ To unsubscribe, mail: [email protected]
smime.p7s
(application/pkcs7-signature, 5.7 KB) - not displayed