| 1 |
On Tue, Jul 5, 2016 at 12:53 PM, james <garftd@×××××××.net> wrote: |
| 2 |
> |
| 3 |
> OK, but with the attic, you can browse by category, read descriptions to get |
| 4 |
> an idea of what is available. Correct me if I'm wrong, but with github, you |
| 5 |
> have to know the name of the packages and that is a limitation when looking |
| 6 |
> back. The attic just makes browsing and retrieval a snap, imho. |
| 7 |
> |
| 8 |
|
| 9 |
More or less. You could probably write a script to go back and find |
| 10 |
all deleted files and restore them. It is also trivial to take a look |
| 11 |
at the Gentoo repo as of a particular point in time. |
| 12 |
|
| 13 |
Or something like this: |
| 14 |
https://stackoverflow.com/questions/6017987/is-there-a-way-in-git-to-list-all-deleted-files-in-the-repository |
| 15 |
|
| 16 |
> |
| 17 |
> OK, I'll give that a whirl. But if I want to go casually looking at old |
| 18 |
> codes, removed from the tree, that I have never used before, but are |
| 19 |
> vaguely referred to in some old post, how do I do that with git? |
| 20 |
|
| 21 |
Just follow the guides I linked. If you have a reference you should |
| 22 |
have a filename. If not then hunt from the log/etc. Also, if you |
| 23 |
have a timestamp on that old post just checkout the tree on that date |
| 24 |
and you have exactly what they were working with. |
| 25 |
|
| 26 |
> |
| 27 |
> So, I guess I'll read up and try to set up my own git repo, so I do not have |
| 28 |
> to delete files as they are pruned from the official portage tree. |
| 29 |
> That is what you are suggesting, right? |
| 30 |
|
| 31 |
No, you clone the Gentoo repo so that you can search it. As files are |
| 32 |
deleted in the repo they'll be deleted in your clone, but you can |
| 33 |
search for them. |
| 34 |
|
| 35 |
If you just wanted to mirror the repo without ever deleting it you |
| 36 |
could do that with rsync, a directory tree, and cron. You should |
| 37 |
stick with git: that's what its for. |
| 38 |
|
| 39 |
Don't worry, your questions just reflect your unfamiliarity with git. |
| 40 |
You really need to grok it to work with it well. We all take some |
| 41 |
time to get there... |
| 42 |
|
| 43 |
> Granted my ignorance of git is a big factor here, so do not be shy to |
| 44 |
> suggest reading materials.... Often I read docs on git and well, I might |
| 45 |
> as well be reading Hieroglyphics. It's easier to follow examples, imho, and |
| 46 |
> that makes support more straight forward and consistent should others need |
| 47 |
> to retrieve old ebuilds and source files. |
| 48 |
|
| 49 |
I get it, but until you actually understand git, the examples will |
| 50 |
eventually get you into trouble. |
| 51 |
|
| 52 |
I'll see if I can find something decent. I had linked something |
| 53 |
earlier and here is another guide: |
| 54 |
http://www.gitguys.com/table-of-contents/ |
| 55 |
|
| 56 |
Do NOT skip descriptions of blobs/trees/commits/objects/reference/etc. |
| 57 |
If you don't understand the data model, you'll never get it. |
| 58 |
Everything is content-hashed with the resulting COW behavior and that |
| 59 |
has a big impact on how it all works. |
| 60 |
|
| 61 |
-- |
| 62 |
Rich |
Archives