# Remove "historical" objects from repository to save place 8 messages from 2006-01-21 to 2006-01-21. Participants: Andrey Borzenkov, Junio C Hamano, Petr Baudis, Randal L. Schwartz. Thread: https://gitlist.dev/t/3120 ## Andrey Borzenkov, 2006-01-21 19:18 Subject: Remove "historical" objects from repository to save place Message-ID: <200601212218.51055.arvidjaar@mail.ru> URL: https://gitlist.dev/e/200601212218.51055.arvidjaar%40mail.ru ``` -----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----- ``` ## Junio C Hamano, 2006-01-21 19:58 Subject: Re: Remove "historical" objects from repository to save place Message-ID: <7v1wz1mjy8.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v1wz1mjy8.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200601212218.51055.arvidjaar@mail.ru> ``` Andrey Borzenkov 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. ``` ## Petr Baudis, 2006-01-21 20:06 Subject: Re: Remove "historical" objects from repository to save place Message-ID: <20060121200615.GM28365@pasky.or.cz> URL: https://gitlist.dev/e/20060121200615.GM28365%40pasky.or.cz In-Reply-To: <7v1wz1mjy8.fsf@assigned-by-dhcp.cox.net> ``` Dear diary, on Sat, Jan 21, 2006 at 08:58:55PM CET, I got a letter where Junio C Hamano 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 ``` ## Junio C Hamano, 2006-01-21 20:25 Subject: Re: Remove "historical" objects from repository to save place Message-ID: <7virsdl44q.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7virsdl44q.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060121200615.GM28365@pasky.or.cz> ``` Petr Baudis 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. ``` ## Randal L. Schwartz, 2006-01-21 20:49 Subject: Re: Remove "historical" objects from repository to save place Message-ID: <86slrhe270.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/86slrhe270.fsf%40blue.stonehenge.com In-Reply-To: <7virsdl44q.fsf@assigned-by-dhcp.cox.net> ``` >>>>> "Junio" == Junio C Hamano 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 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ``` ## Junio C Hamano, 2006-01-21 21:46 Subject: Re: Remove "historical" objects from repository to save place Message-ID: <7vbqy5l0er.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbqy5l0er.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <86slrhe270.fsf@blue.stonehenge.com> ``` merlyn@stonehenge.com (Randal L. Schwartz) writes: >>>>>> "Junio" == Junio C Hamano 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. ``` ## Andrey Borzenkov, 2006-01-21 21:46 Subject: Re: Remove "historical" objects from repository to save place Message-ID: <200601220046.34151.arvidjaar@mail.ru> URL: https://gitlist.dev/e/200601220046.34151.arvidjaar%40mail.ru In-Reply-To: <7v1wz1mjy8.fsf@assigned-by-dhcp.cox.net> ``` -----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----- ``` ## Andrey Borzenkov, 2006-01-21 23:27 Subject: Re: Remove "historical" objects from repository to save place Message-ID: <200601220227.56367.arvidjaar@mail.ru> URL: https://gitlist.dev/e/200601220227.56367.arvidjaar%40mail.ru In-Reply-To: <20060121200615.GM28365@pasky.or.cz> ``` -----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 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----- ```