Tim Blechmann wrote:

...

In case this reaches any other git enthusiasts, I've rigged up a git clone that is automatically tracking boost svn, here:

cool! do you have any plans of also mirroring the boost sandbox svn?

Should I? Why not just put your sandbox code into a git repo and push it someplace public where I can pull from it? One could make a clone of the sandbox to start, but I don't see this as much more convenient than just svn exporting into a git checkout. -t

Christopher Currie wrote:

On Fri, Apr 24, 2009 at 10:20 AM, troy d. straszheim <troy@resophonic.com> wrote:

...

In case this reaches any other git enthusiasts, I've rigged up a git clone that is automatically tracking boost svn, here:

http://sodium.resophonic.com/git/boost/

There actually is another one of these:

http://git.jsharpe.net/boost.git (master) http://repo.or.cz/r/boost.git (mirror) git://repo.or.cz/boost.git (mirror that uses the faster git protocol)

This one has some problems, the release branches aren't mirrored correctly. The one I have up has problems too... things could be a lot easier.

Does it matter, since they're both Git? Well, since you're both doing doing your own imports, the commit hashes are different, so the two repos are incompatible, which is somewhat against the spirit of Git.

Yeah. That the commit hashes are different is a big problem. Brad King from Kitware is here at boostcon and is really good with git... he's shown me a Better Way to do this mirroring that enables one to git svn dcommit directly from the git clone. When I've got this all grokked, I'll give notice here, put the new one up and take the old one down.

While I don't hold out hope that Boost will move to Git anytime soon (pretty please?), perhaps it's time that boost.org have an official Git mirror, so that folks don't end up re-inventing the wheel? Or nominate one of these two (that we know of) to be official?

The thing would be to give it some exercise... I'd be glad to push/pull some changes to you to try everything out. It'd be nice to see some kind of experimental megabranch with various vault code in it, like process and extension. If things really work out well and we know exactly what we want, I think there is some chance that we'd be able to get the mirror put on the same physical machine as the svn repo, which has various advantages over polling the svn repo via the network.

Troy, FWIW your HOWTO is very helpful! I hadn't had a need to submit patches based off of the jsharpe repo, and was a little uncertain how I'd go about it.

Cool, glad to hear it. This should be a lot easier with the new scheme. -t

Christopher Currie wrote:

On Fri, May 8, 2009 at 10:37 AM, troy d. straszheim <troy@resophonic.com> wrote:

...

Yeah. That the commit hashes are different is a big problem. Brad King from Kitware is here at boostcon and is really good with git... he's shown me a Better Way to do this mirroring that enables one to git svn dcommit directly from the git clone. When I've got this all grokked, I'll give notice here, put the new one up and take the old one down.

This is great to hear, I look forward to it.

Okay, I didn't do that. I've left the old one up. All the documentation that I could find and experiments I did indicated that you couldn't push-pull between git repositories and also svn dcommit... and exchanging data between git repositories is much more important than the marginal inconvenience of having to format/apply a patch to an svn checkout (which one can make nearly automatic). So there are still incompatible git repositories floating around, the jsharpe one (which is being updated), and one on gitorious (which hasn't been since january). I'm not sure this matters.... if somebody wants to use git like svn, fine... They wont be pushing/pulling to the other set of clones anyhow.

...

...

While I don't hold out hope that Boost will move to Git anytime soon (pretty please?), perhaps it's time that boost.org have an official Git mirror, so that folks don't end up re-inventing the wheel? Or nominate one of these two (that we know of) to be official? The thing would be to give it some exercise... I'd be glad to push/pull some changes to you to try everything out. It'd be nice to see some kind of experimental megabranch with various vault code in it, like process and extension.

That'd be sweet. Let me know what I can do to help, I've got a gitosis repo I can add you to for testing purposes.

I'm now mirroring to http://gitosis.org/boost as well. Expanded tutorial/docs are here: http://sodium.resophonic.com/boost-git I'm very open to suggestions and may be missing obvious things. So I'd suggest to follow those docs, jotting down notes/corrections as you go. You'll: - clone the boost repo on gitosis - pick your favorite vault/sandbox project and import it - push it to gitosis - ??? - Profit As those docs mention, I did boost.process already, see my trunk_process branch. -t

Vladimir Prus wrote:

This presently has a link to

http://sodium.resophonic.com/boost-git.html

and that one gives 404.

Fixed, thanks for the heads-up. I reworked the docs significantly, they're here: http://sodium.resophonic.com/boost-git/ And they reference new a new git mirror that is up here: http://gitorious.org/boost Which should make the whole process quite a bit easier for the beginner.

<sarcasm> While I do use git myself, I still cannot comprehend how 'git clone' can work for half-an-hour and that produce something where 'git log' throws fits about something called HEAD not existing. </sarcasm>

And now a couple of real questions:

1. Is there any way to simulate branches of subdirectories in git? Like, switching tools/build/v2 to a branch without affecting anything else?

It's easy to just get the code out, git checkout other_branch tools/build/v2 but that checkout isn't tracked. What's the use case? It is easy enough to just create a branch, put your new stuff on it (if it happens to be isolated to one subdirectory, fine) and push it. There are a couple of goodies out there like submodules and the subtree merge strategy that I have yet to play with, maybe these are relevant.

In SVN, we have a branch at: http://svn.boost.org/svn/boost/branches/build/python_port/ which is branched from trunk/tools/build/v2. Now, in git the branch is called 'build', and it contains 'python_port' subdirectory, and that contains entire Boost. It would be mightly inconvenient it switching between trunk and python port branch will change locations of everything.

Git-svn isn't very good at tracking our haphazard organization of branches and tags. That build/python_port branch is worthless. If you want to start working on the python port in gitland while tracking the svn trunk, see those new docs, most of it is one big example of how to do this. In short, you'd: - make a gitorious account and your own boost repo clone - clone your clone down to your local machine - make two local branches, one for private development (and rebasing), one for pushing - svn export your current python port stuff into the git repository and commit. - follow the instructions for fetching, rebasing and pushing as new commits come in to trunk

2. Is this meant as read-only medium, or you envision this becoming preferred place for on-the-side experimentation, such as branches and sandbox?

Well it is my preferred place for experimentation, certainly, and I know I'm not alone. I'm reluctant to do any 'envisioning' at this point. :) I guess we have to wait and see. -t