Partial tree export and merging

Partial tree export and merging

[Heiko Voigt]

Hallo,

I am currently facing a challenge for adding limited access to a git 
repository for the i18n and documentation (language) team. Our 
repository contains *.html and *.loc files which are located along with 
the code. The language team should not see the code. At the same time a 
developer using the full tree needs to be able to contribute to the i8n 
files.

To archieve this I would like to extract a repository that only contains 
the documentation and localization files which can be used by the i8n 
and doc team. This should be regularly merged into the development (with 
code) repository.

My idea of a solution would be to export patches only for the specific 
files and import them into a seperate empty repository/branch using 
git-format-patch and git-am. This seperate repository then itself then
could be imported again with a normal merge operation. Has a anyone 
already solved such a problem or other ideas how to solve this ?

cheers Heiko

Re: Partial tree export and merging

[Shawn O. Pearce]

Heiko Voigt <heiko.voigt@mahr.de> wrote:
>
> I am currently facing a challenge for adding limited access to a git  
> repository for the i18n and documentation (language) team.
...
> To archieve this I would like to extract a repository that only contains  
> the documentation and localization files which can be used by the i8n  
> and doc team. This should be regularly merged into the development (with  
> code) repository.
>
> My idea of a solution would be to export patches only for the specific  
> files and import them into a seperate empty repository/branch using  
> git-format-patch and git-am. This seperate repository then itself then
> could be imported again with a normal merge operation. Has a anyone  
> already solved such a problem or other ideas how to solve this ?

See git-filter-branch.  You can use it to slice the history down
to only contain these files, but still show the full change history
of them (assuming that is what you are trying to get).

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.

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.

-- 
Shawn.

Re: Partial tree export and merging

[Heiko Voigt]

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.

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

cheers Heiko

Re: Partial tree export and merging

[Shawn O. Pearce]

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.

Re: Partial tree export and merging

[Nguyen Thai Ngoc Duy]

On 9/24/08, Heiko Voigt <heiko.voigt@mahr.de> wrote:
> Hallo,
>
>  I am currently facing a challenge for adding limited access to a git
> repository for the i18n and documentation (language) team. Our repository
> contains *.html and *.loc files which are located along with the code. The
> language team should not see the code. At the same time a developer using
> the full tree needs to be able to contribute to the i8n files.

That could be done with (under-developing) sparse checkout. Basically
language team's people do "git clone --sparse-checkout='*.loc:*.html'
your-repo.git". Then they only have *.loc and *.html files in working
directory. When they commit, all other files are unchanged. Developers
merge to have updated *.log/html as usual.

I have a question though: is language team allowed to checkout/modify
files other than *.loc and *.html?
-- 
Duy

Re: Partial tree export and merging

[Heiko Voigt]

Nguyen Thai Ngoc Duy schrieb:
> That could be done with (under-developing) sparse checkout. Basically
> language team's people do "git clone --sparse-checkout='*.loc:*.html'
> your-repo.git". Then they only have *.loc and *.html files in working
> directory. When they commit, all other files are unchanged. Developers
> merge to have updated *.log/html as usual.

Where is that option ? Or are you suggesting me to implement it ?

> I have a question though: is language team allowed to checkout/modify
> files other than *.loc and *.html?

Well in an ideal world they should only have access to the "language" 
files. But it is not crucial for us if they get access to the source. 
Its more an issue of user friendlyness. The revision control which is in 
place at the moment does allow them to selectively check out those files.

Heiko

Re: Partial tree export and merging

[Nguyen Thai Ngoc Duy]

On 9/25/08, Heiko Voigt <heiko.voigt@mahr.de> wrote:
> Nguyen Thai Ngoc Duy schrieb:
>
> > That could be done with (under-developing) sparse checkout. Basically
> > language team's people do "git clone
> --sparse-checkout='*.loc:*.html'
> > your-repo.git". Then they only have *.loc and *.html files in working
> > directory. When they commit, all other files are unchanged. Developers
> > merge to have updated *.log/html as usual.
> >
>
>  Where is that option ? Or are you suggesting me to implement it ?

As I said, it is being developed. It should not be used in production
environment yet but if you want to try, you can get it from here

http://repo.or.cz/w/git/pclouds.git in branch sparse-checkout

> > I have a question though: is language team allowed to checkout/modify
> > files other than *.loc and *.html?
> >
>
>  Well in an ideal world they should only have access to the "language"
> files. But it is not crucial for us if they get access to the source. Its
> more an issue of user friendlyness. The revision control which is in place
> at the moment does allow them to selectively check out those files.

Thanks. Just wanted to know the scenario that sparse checkout could be used.
-- 
Duy