On Sun, 2010-01-03 at 08:29 +0545, Bryan Berry wrote: > > I am wary of experimenting when the gslo infrastructure is still in > flux. I would rather stick w/ gitweb or cgit and then move to whatever > becomes of gslo. Should we start w/ cgit or gitweb? >
An alternative to installing a local multi-repository interface just occurred to me. To solve the data transfer issue, git offers a pletora of bandwidth-saving options. One possibility is to let the Nepali developers clone from each other's repository: git clone --reference officemate.local:~bryanwb/src/karma \ git://git.sugarlabs.org/karma/mainline.git karma Alternatively, you could rsync the files to your local machine: rsync -aP officemate.local:~bryanwb/src/karma/.git karma-ref.git git clone --reference karma-ref.git \ git://git.sugarlabs.org/karma/mainline.git karma It doesn't matter if the reference repository contains unwanted changes or hasn't been updated for a while. Any good bits will be reused, and the rest will be fetched remotely. Other tips: * Never use the http protocol, as it is quite inefficient. * try passing the --thin option when you pull. The server-side will work harder to minimize file transfers. * Another way to speed-up initial cloning is to limit the number of revisions with --depth. It's usually not a big deal, unless your history contains lots of large files that were subsequently deleted. * If your history contains plenty of similar files, for example PNGs that have been merely moved around, you'd benefit by repacking your repository with larger --window and --depth parameters. You could repack locally and, when you're happy with the result, push it to Gitorious with "git push --mirror". * If your history is badly messed up, you may "edit" it locally with a combination of the advanced git operations such as "git rebase --interactive", "git reset --hard" and "git commit --amend". When you publish the resulting edited history, people who had previously cloned from you will have to refetch. Needless to say, git's arsenal of history-rewriting commands is as dangerous as it is powerful. * the git:// protocol is probably slightly faster than using the ssh tunnel. You can easily switch between the two using "git remote ..." or by editing .git/config manually. Free git advice is available from me on #sugar, GMT-5 office hours. Next business day, on-site support contracts available on demand. Git is a registered trademark of Stupid Version Control Systems, Inc. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel