Re: Partial tree export and merging

["Shawn O. Pearce" <spearce@spearce.org>]

Heiko Voigt <heiko.voigt@mahr.de> wrote:
> Shawn O. Pearce schrieb:
>> Once the history is split into a new "doc+html" repository have
>> developers _only_ edit the docs/html in the doc+html repository,
>> don't make more edits in the source code repository.
>
> The problem with committing into 2 repositories (only merging from one  
> side) is that the docs/html also contain localization files which make  
> it hard to work/test the code because localization strings are initially  
> added by the developers. They would then have to change in the 2nd repo  
> and pull for testing.

I can see how that would be difficult.

In think you are faced with either restructuring your tree so that
the docs/html/localization files are all under a single subdirectory,
or you have to keep splitting down the repository with something like
filter-branch (or your own tools) to update the localization tree.

Doing the latter risks more merge conflicts for developers when they
pull changes back from the localization team.  Usually a developer
doesn't want to d3eal with merge conflicts from doc writers, and
they really don't want to deal with them in localized files if they
can't read/write that language.

>> You can use git-submodule or git-merge with the subtree strategy
>> to pull changes from the doc+html repository into the main source
>> repository.
>
> Would git submodule work with this kind of layout? Same folders  
> containing different files. I thought submodules only work with  
> subdirectories which are itself a git repo.

You are correct, a submodule requires that everything in that
directory be part of that submodule.  If your source tree has the
"submodule files" spread all over, intermingled with sources,
you can't use submodule to manage them.

Typically the recommendation is to organize your source tree more
by functional responsibility, so you can delegate all files under
a single directory to the docs team.  The project scales better to
more staff, and its easier to avoid merge conflicts.

-- 
Shawn.