Re: help moving boost.org to git
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- Jul 6, 2010, 17:27 UTC
- Message-ID
- <AANLkTikkKhvzsczKJwjsc0kmCmWQGAIUzc__Wr20Dbwd@mail.gmail.com>
- In-Reply-To
- <4C3275C0.8000406@boostpro.com>
On Mon, Jul 5, 2010 at 8:16 PM, Eric Niebler <eric@boostpro.com> wrote:
Show 11 quoted lines
> 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.
Show 5 quoted lines
> 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.
Show 8 quoted lines
>> 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