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

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

[Stas Cherkassky]

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!!

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

[Andrew Ardill]

On 29 October 2013 15:42, Stas Cherkassky <scherkas@gmail.com> wrote:
> 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.

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.

> 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 ?

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

Regards,

Andrew Ardill

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

[Stas Cherkassky]

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

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

[Jakub Narębski]

On 2013-10-30 08:52, Stas Cherkassky wrote:
>
> Shallow clone (if that's what you meant) is not suitable because it
> doesn't allow to push/pull to/from this shallow repository.

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

> 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..

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.

-- 
Jakub Narębski

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

[Duy Nguyen]

On Wed, Oct 30, 2013 at 10:55 PM, Jakub Narębski <jnareb@gmail.com> wrote:
> On 2013-10-30 08:52, Stas Cherkassky wrote:
>>
>>
>> Shallow clone (if that's what you meant) is not suitable because it
>> doesn't allow to push/pull to/from this shallow repository.
>
>
> Still?  I think there were some work on making shallow clone to
> allowing push/pull to/from it.

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.
-- 
Duy