threads / discuss / 15649

Partial tree export and merging

Subject: Partial tree export and merging

## tl;dr

7 messages between Sep 24, 2008 and Sep 25, 2008.

replies: 6people: 3as markdown or json

Heiko Voigt· Sep 24, 2008, 13:58 UTC · lore
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
Shawn O. Pearce· Sep 24, 2008, 14:39 UTC · re: Heiko Voigt · lore

Re: Partial tree export and merging

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.
...
Show 10 quoted lines
> 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.
Heiko Voigt· Sep 24, 2008, 15:05 UTC · re: Shawn O. Pearce · lore

Re: Partial tree export and merging

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
Shawn O. Pearce· Sep 24, 2008, 15:13 UTC · re: Heiko Voigt · lore

Re: Partial tree export and merging

Heiko Voigt <heiko.voigt@mahr.de> wrote:
Show 10 quoted lines
> 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.

Show 7 quoted lines
>> 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.
Nguyen Thai Ngoc Duy· Sep 24, 2008, 17:51 UTC · re: Heiko Voigt · lore

Re: Partial tree export and merging

On 9/24/08, Heiko Voigt <heiko.voigt@mahr.de> wrote:
Show 7 quoted lines
> 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
Heiko Voigt· Sep 25, 2008, 14:36 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: Partial tree export and merging

Nguyen Thai Ngoc Duy schrieb:
Show 5 quoted lines
> 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
Nguyen Thai Ngoc Duy· Sep 25, 2008, 14:51 UTC · re: Heiko Voigt · lore

Re: Partial tree export and merging

On 9/25/08, Heiko Voigt <heiko.voigt@mahr.de> wrote:
Show 11 quoted lines
> 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
Show 8 quoted lines
> > 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

← back to recent threads