[dev] Split Git

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> 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.

What's your reasoning to still have a monolith repo with sub-trees,  
even if only privately, locally? I understand that want to keep the  
workflow as close to the current workflow as possible. Though as you  
already mentioned, this won't work without scripts and tools for that  
anyway.
My question is, what benefit do we have, managing a monolith, or  
container repo repository locally, opposed to having those tools and  
scripts just manage the individual repositories in a local container  
*directory*. I see that being able to git-commit from the base  
directory is a good thing. But if this only works by later splitting  
this commit to the individual repos through tools, why not having this  
tool making the "base" commit right from the start? Or is it possible  
to use the split tools automatically from git hooks?

-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject