On Tue, Jul 5, 2016 at 12:53 PM, james <gar...@verizon.net> wrote: > > OK, but with the attic, you can browse by category, read descriptions to get > an idea of what is available. Correct me if I'm wrong, but with github, you > have to know the name of the packages and that is a limitation when looking > back. The attic just makes browsing and retrieval a snap, imho. >
More or less. You could probably write a script to go back and find all deleted files and restore them. It is also trivial to take a look at the Gentoo repo as of a particular point in time. Or something like this: https://stackoverflow.com/questions/6017987/is-there-a-way-in-git-to-list-all-deleted-files-in-the-repository > > OK, I'll give that a whirl. But if I want to go casually looking at old > codes, removed from the tree, that I have never used before, but are > vaguely referred to in some old post, how do I do that with git? Just follow the guides I linked. If you have a reference you should have a filename. If not then hunt from the log/etc. Also, if you have a timestamp on that old post just checkout the tree on that date and you have exactly what they were working with. > > So, I guess I'll read up and try to set up my own git repo, so I do not have > to delete files as they are pruned from the official portage tree. > That is what you are suggesting, right? No, you clone the Gentoo repo so that you can search it. As files are deleted in the repo they'll be deleted in your clone, but you can search for them. If you just wanted to mirror the repo without ever deleting it you could do that with rsync, a directory tree, and cron. You should stick with git: that's what its for. Don't worry, your questions just reflect your unfamiliarity with git. You really need to grok it to work with it well. We all take some time to get there... > Granted my ignorance of git is a big factor here, so do not be shy to > suggest reading materials.... Often I read docs on git and well, I might > as well be reading Hieroglyphics. It's easier to follow examples, imho, and > that makes support more straight forward and consistent should others need > to retrieve old ebuilds and source files. I get it, but until you actually understand git, the examples will eventually get you into trouble. I'll see if I can find something decent. I had linked something earlier and here is another guide: http://www.gitguys.com/table-of-contents/ Do NOT skip descriptions of blobs/trees/commits/objects/reference/etc. If you don't understand the data model, you'll never get it. Everything is content-hashed with the resulting COW behavior and that has a big impact on how it all works. -- Rich
