Re: help moving boost.org to git

[Avery Pennarun <apenwarr@gmail.com>]

On Mon, Jul 5, 2010 at 8:16 PM, Eric Niebler <eric@boostpro.com> wrote:
> On 7/5/2010 7:32 PM, Avery Pennarun wrote:
>> Eric Niebler wrote:
>>> If multiple repositories share the same ancient history, wouldn't that
>>> give git annotate/blame enough information? Sorry, git newbie here.
>>
>> Yes, it would.  But how much of the ancient history do you want?  If
>> you want all of it, you don't save any space in your repo.
>
> Repos, plural. We'd save space because the history wouldn't be
> duplicated in each one. Right? Or else I'm confused and this something
> that will become clear after I understand what git subtree does.

The statement "multiple repositories share the same ancient history"
above is the part that's confusing.  If you use a tool like
git-subtree or git-filter-branch, you're actually generating a "new
history" based on the original history.  The "new history" obviously
contains fewer files than the original, which would take less space.
But if you want multiple repositories to "share the same ancient
history" you can't rewrite it, and thus you aren't saving any space in
any one repo.

I'm assuming you want to rewrite history to save space (since that's
what this thread is about).  And git annotate/blame will work as long
as your rewritten history contains all the files you care about in
that repo.

> Right now, the other boost developers are pushing for a solution that
> uses grafts. I'm fuzzy on what they are exactly, but it seems that we'd
> freeze a svn mirror and have anybody interested in history put grafts in
> their local repository pointing back at the mirror. I don't know enough
> yet to say what the pros/cons of this approach might be wrt git subtree.

The primary advantage of grafts is that you can do something easy
*right now* and then fix it all up later.  eg. if you screw up your
history extraction and do it better later, you can just re-graft it
and you're done.

A secondary advantage of grafts is that cloning the "primary"
repository will be tiny since it doesn't have much ancient history.

A disadvantage of grafts is that each user has to deal with grafts in
his cloned repo, and unless he does, things like 'git log' and 'git
blame' won't show anything from the grafted history.  Supposedly 'git
replace' was designed to help with this issue, but I've never used it
so I don't know for sure.

And of course, grafts don't actually do any history rewriting for you.
 You could split out a subtree's history and then graft it on, but the
splitting process is still the same as it would be without grafts.
The alternative would be to *not* rewrite history, just keep the
entire history of the whole project in one place, and graft it on if
you really need it.  That's actually pretty clean (and accurately
reflects exactly what *really happened*, which is a nice feature to
have in a vcs history), but you'll then never have a single repo of
just one subproject with the entire history of that subproject.  That
latter turns out to not actually be very important in practice, so you
might want to do it.

>> The confusing part is taking *submissions* back through both channels.
>> If you value your sanity, you probably want to only allow submissions
>> back via svn while you're running the two in parallel; but that makes
>> git's added features a lot less useful, so you probably want to run in
>> parallel for only a short time.
>
> Oh my! I don't think we'd open the git repositories for changes until
> after we close down svn. This problem is hard enough.

It can be done, and I've done it :)  But you're wise to avoid that situation.

Have fun,

Avery