Re: collapsing old git history to reduce repo size, while preserving commit #s and tags

Hi,

I have an old git repo with e.g. 1000 commits, that grew up to considerable size. Now, I am starting a new project and want to use this repo, but "slimmed down".

I'd like to clone the repo to the new project and "slim it down" I'd like to collapse 900 first commits into one, but keep last 100, with their commit numbers and tags. I also want to be able to push and merge changes from the old repo to the new one.

I've read about git rebase, but it seems to tamper with commit numbers and looses tags.. Is there any other way to have it done ?

thanks!!

On 29 October 2013 15:42, Stas Cherkassky <scherkas@gmail.com> wrote:

If you want to change the actual history of your repository, it will be largely incompatible with the original, and this is by design. You don't want somebody being able to change your history without you knowing about it.

It sounds like a shallow checkout might be appropriate for you, try looking that up.

Regards,

Andrew Ardill

Andrew,

Shallow clone (if that's what you meant) is not suitable because it doesn't allow to push/pull to/from this shallow repository.

I understand that generally git is designed to preserve the history. But the problem is real, and probably is not unique to our project. The fact that there ARE some ways to modify history (collapse commits, rebase, filter-branch) made me hopeful that what I need is also possible..

thanks, Stas

On 2013-10-30 08:52, Stas Cherkassky wrote:

Still? I think there were some work on making shallow clone to allowing push/pull to/from it.

By the very nature of git, namely that the 'parent' link to previous (as in: this is based on it) commit or commits, is SHA-1 of said commit, and SHA-1 identifier of commit is based on contents including 'parent' field.

Both rebase and filter-branch _rewrite_ history (i.e. make modified copy of history, and let you replace old history by new).

You could try to use father or shallow clone, namely *grafts*, to 'cauterize' history, but there remains same problems as with shallow clone, perhaps with exception that git won't check things for you.

On Wed, Oct 30, 2013 at 10:55 PM, Jakub Narębski <jnareb@gmail.com> wrote:

Yes, still :-) I've got a proof of concept, but it needs more work to address the concern about its automatically turning a full repo into a shallow one.