Re: separate git tree for docs

[Johannes Schindelin]

Hi,

On Sun, 27 Jul 2008, Graham Percival wrote:

> A month or two ago, there was some discussion about changing the way git 
> is managed, to allow doc writers to have permission to change 
> Documentation/user/ but not other parts of the tree.  At the time I 
> begged everybody to shelve the discussion for a few weeks until I wasn't 
> so busy.  I'm now no longer busy, so it might be good to resume the 
> discussion.
> 
> As an idea of the requirements: I currently anticipate 6 people (not 
> currently listed as members of the devel team) who should have commit 
> ability to Documentation/user/ after GDP.  1 of those people is also a 
> translator, which may or may not be a different branch/tree/whatever.  
> Another 1 of those people should also have commit ability to the entire 
> tree. (more details about these people can be found in the "post-GDP doc 
> team" email)
> 
> I predict that at most two other people should be granted commit ability 
> to Documentation/user/ in the next 12 months.
> 
> 
> Given this situation, I'm not at all certain that it's worth making a 
> separate branch or cloned git tree for docs.  But I'll leave that 
> decision to people who know more about git.

I think the easiest thing _would_ be to have a fork.  There you can do 
everything freely, whatever you wish.  When you're done, somebody who has 
push permissions to the main repository can be asked to pull.

After the pull, there is this wonderful diffstat showing what was changed.  
If that person sees anything changed outside of Documentation/user/, the 
merge can be undone, without ever having been published.  Of course, after 
that will come the request to clean up the doc repository to _not_ include 
changes outside of Documentation/user.

Just my 2 cents,
Dscho