[dev] Split Git

[Michael J Rubinsky]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5869 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20141113/b1d9b68c/attachment.bin>