On 7/6/2010 1:27 PM, Avery Pennarun wrote: > On Mon, Jul 5, 2010 at 8:16 PM, Eric Niebler <eric@xxxxxxxxxxxx> 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 think I have reached understanding! Thank you. It *would* save if I pull down, say, 100 of these new repos+ancient history because git would just store the ancient history locally once. I'm also guessing git is smart enough to avoid /downloading/ the ancient history 100x. > 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. I now understand that, too. >> 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. How does one screw up the history extraction, if one is not doing any fancy history rewriting (in this scenario)? Be there dragons? > A secondary advantage of grafts is that cloning the "primary" > repository will be tiny since it doesn't have much ancient history. Right. Only those who ask for it will pay for it. And only developers will have need of it, and not all developers at that. > 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. I'll add it to the list of things to learn about. > 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. That's starting to sound pretty good. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html