Re: partial checkouts

[Aidan Van Dyk <aidan@highrise.ca>]

If all you're looking for is a "single set of read-only docs" conglomeration of
all the KDE submodules projects documentation so you can translate them, what
about using "archive"?  Since archive takes a "tree-ish", and work on remote
upload-pack servers (if it's enabled), you can get an un-versioned "remote
partial checkout" with something like do things like:
	git archive --format=tar --prefix=git/Documentation/ --remote=git://repo.or.cz/git.git HEAD:Documentation | tar tf - | head
	git archive --format=tar --prefix=/opt/git/share/man/ --remote=git://repo.or.cz/git.git man | tar tf -



So, this could be simply scripted to give you a repo with *all* modules docs/ inside a single repo...
	for m in $MODULES
	do
		git archive --format=tar --prefix="$m/$DOCDIR/" --remote=$REMOTE_BASE/$m $BRANCH:$DOCDIR | tar xf -
		git add $m/$DOCDIR
		git commit $m/$DOCDIR -m "$m: Automatic import"
	done

Do that in a central location an dlet translators pull that...  Everythings
"duplicated", but git's object store will help out there...  You loose the
history of the original docs, but for translations, you you're not translating
the history anyways, your'e translation the docs at a point in time...

Or just dump all thd docs in a .gitignore'd subdirctory and have translators
run a script to update them.

a.


> On Sat, May 23, 2009 at 8:26 PM, Chani <chanika@gmail.com> wrote:
> > On May 23, 2009 16:34:53 Johan Herland wrote:
> >> On Saturday 23 May 2009, Chani wrote:
> >> > I'm kinda wondering if there'd be a way to use git-filter-branch to make
> >> > a repo that only tracks the doc/ folder for a module - but I've no idea
> >> > whether it'd have to be recreated from scratch every time someone changes
> >> > something in the real repo's doc/
> >> >
> >> > can anyone think of a less ugly solution?
> >> > what are the chances of git supporting this kind of partial checkout
> >> > someday?
 
> Here's something that might work.  Write a script that runs on a
> server somewhere.  It checks out all of the git-managed KDE
> components, including documentation (it's okay to do this from one
> place, right?).  Then it loops through all the documentation
> subdirectories and splits them out into individual projects/branches
> with 'git subtree split'.
> 
> You could then make a new project, kde-docs for example, that pulls
> those new doc projects back together into a single project, using 'git
> subtree merge'.
> 
> People could then checkout the single kde-docs project and get all
> the docs, then make changes and push them back upstream to you.  As
> far as the average person is concerned, this is probably even easier
> than svn:externals - they don't have to remember to commit in each
> subdirectory separately, as git-subtree rips it all apart later.  Also
> note that *end users* never have to operate the git subtree command;
> all that happens behind the scenes on your server.
> 
> Later, you use 'git subtree split' to rip it apart back into the
> individual projects, and 'git subtree merge' those back into their
> original git repositories.
> 
> Since git-subtree is my own little toy and it's designed for exactly
> this kind of workflow, I'd be happy to help you debug a script for
> this if you like.  Probably I'll learn something.
> 
> Disclaimer: git-subtree hasn't been used by too many people yet and we
> may end up finding some bugs.
> 
> Have fun,
> 
> Avery
>