Remove "historical" objects from repository to save place

Remove "historical" objects from repository to save place

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is it possible to conserve space by removing old versions? Let's say I am not 
interested in kernel versions before 2.6.15 - is it possible to remove them 
from repository cloned from one of "official" ones (Linus or stable).

Description of git-prune suggests that it may be possible by removing tags 
from refs/tags; OTOH I may have commit chain that will prevent them. Also 
won't those tags come back after git fetch --tags?

TIA

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD0okaR6LMutpd94wRAqEZAKC5VAkNMlL9TEmgELynIUf24Dd9oQCeOejQ
Mdmc4lFsYXBHqofjQhgEIlU=
=2j5N
-----END PGP SIGNATURE-----

Re: Remove "historical" objects from repository to save place

[Junio C Hamano]

Andrey Borzenkov <arvidjaar@mail.ru> writes:

> Description of git-prune suggests that it may be possible by removing tags 
> from refs/tags

If the documentation suggests that, then it is misleading.

> OTOH I may have commit chain that will prevent them.

Correct.

> Also 
> won't those tags come back after git fetch --tags?

Correct.

You might be able to cauterize the history at a specific commit
and then re-clone.  I've talked about how in "[QUESTION] about
.git/info/grafts file" thread yesterday, so I won't repeat that.

Re: Remove "historical" objects from repository to save place

[Petr Baudis]

Dear diary, on Sat, Jan 21, 2006 at 08:58:55PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> You might be able to cauterize the history at a specific commit
> and then re-clone.  I've talked about how in "[QUESTION] about
> .git/info/grafts file" thread yesterday, so I won't repeat that.

Shouldn't the git-prune be sufficient after cauterizing the history?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Re: Remove "historical" objects from repository to save place

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>> You might be able to cauterize the history at a specific commit
>> and then re-clone.  I've talked about how in "[QUESTION] about
>> .git/info/grafts file" thread yesterday, so I won't repeat that.
>
> Shouldn't the git-prune be sufficient after cauterizing the history?

Logically yes, but practically no.

Most likely what the original requestor cloned from Linus has
been already packed so git-prune would not do much.

Re: Remove "historical" objects from repository to save place

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:

Junio> Most likely what the original requestor cloned from Linus has
Junio> been already packed so git-prune would not do much.

Wait.  Does that mean that:

$ git-checkout -b playground
$ work work work
$ git-commit -m 'snapshot'
$ git-checkout -b master
$ git-repack -a -d

means that even if I do

$ git-branch -d playground
$ git-repack -a -d

I still have the commit from playground as objects inside my one big pack?

Ick.  How do I make that go away?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Remove "historical" objects from repository to save place

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> Most likely what the original requestor cloned from Linus has
> Junio> been already packed so git-prune would not do much.
>
> Wait.  Does that mean that:
>
> $ git-checkout -b playground
> $ work work work
> $ git-commit -m 'snapshot'
> $ git-checkout -b master
> $ git-repack -a -d
>
> means that even if I do
>
> $ git-branch -d playground
> $ git-repack -a -d
>
> I still have the commit from playground as objects inside my one big pack?

Repack retraces from all the available refs, so that is fine.

Pasky was talking about prune, which is a different animal.

Re: Remove "historical" objects from repository to save place

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 21 January 2006 23:06, Petr Baudis wrote:
> Dear diary, on Sat, Jan 21, 2006 at 08:58:55PM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>
> > You might be able to cauterize the history at a specific commit
> > and then re-clone.  I've talked about how in "[QUESTION] about
> > .git/info/grafts file" thread yesterday, so I won't repeat that.
>
> Shouldn't the git-prune be sufficient after cauterizing the history?

this did not work for me, at least applied naively. May be, it is due to the 
way I setup repository - first I created local version from 2.6.15 tree and 
then pulled in remote one.

Anyway repacking and pruning resulted in over 500MB size reduction so its OK 
for me so far. I'll probably try fetching cleanly later.

thank you and best regards

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD0sN8R6LMutpd94wRAt1WAKC18LjAl+MbyfmvSvvNQGUF/mlbIgCfcu6s
nuZtYttRsd673Yqlq3aKr+A=
=B6jN
-----END PGP SIGNATURE-----

Re: Remove "historical" objects from repository to save place

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 21 January 2006 22:58, Junio C Hamano wrote:
>
> You might be able to cauterize the history at a specific commit
> and then re-clone.  I've talked about how in "[QUESTION] about
> ..git/info/grafts file" thread yesterday, so I won't repeat that.

thank you, quite complete description. One question - any caveats in using git 
ls-remote to fetch graft point?

echo $(git ls-remote 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v2.6.15 
| cut -f1) > .git/info/grafts

etc

this avoids downloading over 1G in the first place.

regards

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD0qu6R6LMutpd94wRAtuzAJoCT15+8d9BcIEhOxmD9lrRGWE6EQCghg5l
SR5g1+nAUNlltYyXydxsFAs=
=U2cu
-----END PGP SIGNATURE-----