[dev] Split Git
Michael J Rubinsky
mrubinsk at horde.org
Fri Nov 14 16:47:28 UTC 2014
Quoting Jan Schneider <jan at horde.org>:
> 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.
It's not that this won't work without the tools, but rather makes it
easier, by combining a few commands. I do see the point you are making
though (see below).
> 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?
Yes, mostly it's to take advantage of git's functionality and our
existing tool set. Not only for git-commit from the base directory,
but things like diff|status|log as well. The latter may be of dubious
value if you choose to always squash the subtree updates, though on
the other hand, this would result in only changes made locally showing
in the log.
Yes, a git hook *could* be used for this, but I doubt that is what we
want since the subtree-split process appears be relatively slow. I
suppose we could just create a small wrapper script around git for
checking all the modules for changes etc...
My original thinking was that it would be easy to see what changes
haven't been staged/committed yet, easier to do a git log for
recently made changes etc... Otherwise, each module would need a
separate git status. Now, thinking about this more after a good
night's rest, I see that this might be too much work/overhead for such
a gain. Especially since we would end up scripting a bunch of this
stuff anyway. Also, the subtree-split operation is fairly slow.
So, I guess you are right...this is adding another layer of complexity
that isn't strictly necessary. Another minor point is that since
releases are from the individual repositories, the "original" repos
would need to be checked out locally as well anyway.
Of course, since all of this is local-only I guess it really doesn't
matter which approach is used since the only visible end results are
pushes to individual repositories. I guess Gunnar's idea sounded neat
and promising, and I was trying to work with something similar. :)
Either way, glad to get the conversation going on this again.
--
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/20141114/d0959223/attachment.bin>
More information about the dev
mailing list