Re: [gentoo-user] Re: attic

[Alan McKinnon]

On Mon, Sep 4, 2023 at 2:36 PM Rich Freeman  wrote:

> On Mon, Sep 4, 2023 at 4:38 AM William Kenworthy 
> wrote:
> >
> > On 4/9/23 16:04, Nuno Silva wrote:
> > >
> > > (But note that Rich was suggesting using the *search* feature of the
> > > gitweb interface, which, in this case, also finds the same topmost
> > > commit if I search for "reedsolomon".)
> > >
> > tkx, missed that!
>
> Note that in terms of indexing git and CVS have their pros and cons,
> because they use different data structures.  I've heard the saying
> that Git is a data structure masquerading as an SCM, and certainly the
> inconsistencies in the command line operations bear that out.
>

I'd always heard that Git is a file system and all useful side effects are
pure luck

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: attic

[Rich Freeman]

On Mon, Sep 4, 2023 at 4:38 AM William Kenworthy  wrote:
>
> On 4/9/23 16:04, Nuno Silva wrote:
> >
> > (But note that Rich was suggesting using the *search* feature of the
> > gitweb interface, which, in this case, also finds the same topmost
> > commit if I search for "reedsolomon".)
> >
> tkx, missed that!

Note that in terms of indexing git and CVS have their pros and cons,
because they use different data structures.  I've heard the saying
that Git is a data structure masquerading as an SCM, and certainly the
inconsistencies in the command line operations bear that out.  Git
tends to be much more useful in general, but for things like finding
deleted files CVS was definitely more time-efficient.

The reason for this is that everything in git is reachable via
commits, and these are reachable from a head via a linked list.  The
most recent commit gives access to the current version of the
repository, and a pointer to the immediately previous commit(s).  To
find a deleted file, git must go to the most recent commit in whatever
branch you are searching, then descend its tree to look for the file.
If it is not found, it then goes to the previous commit and descends
that tree.  There are 745k commits in the active Gentoo repository.  I
think there are something like 2M of them in the historical one.  Each
commit is a random seek, and then each step down the directory tree to
find a file is another random seek.

In CVS everything is organized first by file, and then each file has
its own commit history.  So finding a file, deleted or otherwise, just
requires a seek for each level in the directory tree.  Then you can
directly read its history.

So finding an old deleted file in the gentoo git repo can require
millions of reads, while doing so in CVS only required about 3.  It is
no surprise that the web interfaces were designed to make that
operation much easier - if you do sufficiently complex searches in the
git web interface it will time you out to avoid bogging down the
server, which is why some searches may require you to clone the repo
and do it locally.

Now, if you want to find out what changed in a particular commit the
situation is reversed.  If you identify a commit in git and want to
see what changed, it can directly read the commit from disk using its
hash.  It then looks at the parent commit, then descends both trees
doing a diff at each level.  Since everything is content-hashed only
directory trees that contain differences need to be read.  If a commit
had changes to 50 files, it might only take 10 reads to figure out
which files changed, and then another 100 to compare the contents of
each file and generate diffs.  If you wanted to do that in CVS you'd
have to read every single file in the repository and read the
sequential history of each file to find any commits that have the same
time/author.  CVS commits also aren't atomic so ordering across files
might not be the same.

Git is a thing of beauty when you think about what it was designed to
do and how well-suited to this design its architecture is.  The same
can be said of several data-driven FOSS applications.  The right
algorithm can make a huge difference...

-- 
Rich

Re: [gentoo-user] Re: attic

[William Kenworthy]

On 4/9/23 16:04, Nuno Silva wrote:

On 2023-09-04, William Kenworthy wrote:


On 3/9/23 18:29, Rich Freeman wrote:

On Sun, Sep 3, 2023 at 4:44 AM Michael  wrote:

On Sunday, 3 September 2023 07:49:36 BST William Kenworthy wrote:

Hi , I used to be able to get old ebuilds from "the attic" but I cant
find it on google - is it still around?

Perhaps have a look here at the archives?

https://gitweb.gentoo.org/

The archives will only contain data migrated from CVS - so only things
from more than a few years ago.

You want to look into the main repo for anything recently deleted.

[...]

This can be done via the website, though the search capability is a
little limited.  I ended up having to search from a local clone
because your package name contains an error and the web search found
nothing.

To find your file, go to:
https://gitweb.gentoo.org/repo/gentoo.git/
Go to the search box in the top right and search for:
dev-python/reedsolomon (note that the package category is
different from what was in your email)
Find the commit one commit before the one that removed your package.
(ie one that contains your package in its most recent version)  If you
find the one that deleted your file, then just look at the parent in
the commit header and click on that to go back one version where it is
still present.
Click the tree hash to browse the historical version of the repository
that existed before your file was deleted.
For example, you can find v1.6.1 of that package at:
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/reedsolomon/reedsolomon-1.6.1.ebuild?id=149a131188ebce76a87fd8363fb212f5f1620a02

[...]

The web git interface is capable of displaying past commits.  It just
can't search for wildcards/etc.


Thanks Rich,

unfortunately the web interface isn't helpful - I cant just navigate
the tree to find commits -
"https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/reedsolomon/;
gives path not found - it looks like you have to know the commit first
by downloading the git tree to search it - not friendly at all!

With /log/ instead of /tree/ in the URL it at least shows the list of
commits. From a quick check, this seems to include the commit removing
the directory when it's removed instead of renamed, so hopefully it
helps too with retrieving older ebuilds?

(But note that Rich was suggesting using the *search* feature of the
gitweb interface, which, in this case, also finds the same topmost
commit if I search for "reedsolomon".)


tkx, missed that!

BillK

[gentoo-user] Re: attic

[Nuno Silva]

On 2023-09-04, William Kenworthy wrote:

> On 3/9/23 18:29, Rich Freeman wrote:
>> On Sun, Sep 3, 2023 at 4:44 AM Michael  wrote:
>>> On Sunday, 3 September 2023 07:49:36 BST William Kenworthy wrote:
 Hi , I used to be able to get old ebuilds from "the attic" but I cant
 find it on google - is it still around?
>>> Perhaps have a look here at the archives?
>>>
>>> https://gitweb.gentoo.org/
>> The archives will only contain data migrated from CVS - so only things
>> from more than a few years ago.
>>
>> You want to look into the main repo for anything recently deleted.
[...]
>> This can be done via the website, though the search capability is a
>> little limited.  I ended up having to search from a local clone
>> because your package name contains an error and the web search found
>> nothing.
>>
>> To find your file, go to:
>> https://gitweb.gentoo.org/repo/gentoo.git/
>> Go to the search box in the top right and search for:
>> dev-python/reedsolomon (note that the package category is
>> different from what was in your email)
>> Find the commit one commit before the one that removed your package.
>> (ie one that contains your package in its most recent version)  If you
>> find the one that deleted your file, then just look at the parent in
>> the commit header and click on that to go back one version where it is
>> still present.
>> Click the tree hash to browse the historical version of the repository
>> that existed before your file was deleted.
>> For example, you can find v1.6.1 of that package at:
>> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/reedsolomon/reedsolomon-1.6.1.ebuild?id=149a131188ebce76a87fd8363fb212f5f1620a02
[...]
>> The web git interface is capable of displaying past commits.  It just
>> can't search for wildcards/etc.
>>
> Thanks Rich,
>
> unfortunately the web interface isn't helpful - I cant just navigate
> the tree to find commits - 
> "https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/reedsolomon/;
> gives path not found - it looks like you have to know the commit first
> by downloading the git tree to search it - not friendly at all!

With /log/ instead of /tree/ in the URL it at least shows the list of
commits. From a quick check, this seems to include the commit removing
the directory when it's removed instead of renamed, so hopefully it
helps too with retrieving older ebuilds?

(But note that Rich was suggesting using the *search* feature of the
gitweb interface, which, in this case, also finds the same topmost
commit if I search for "reedsolomon".)

-- 
Nuno Silva

[gentoo-user] Re: Attic files (app-admin/rackview) removed?

[James]

Jonathan Callen  gentoo.org> writes:


> First, you must do the `cvs co` *without* the "-P" flag (check your
> ~/.cvsrc). You can bypass a ~/.cvsrc by passing "-f" to cvs, like so:

> CVSROOT=":pserver:anonymous  anoncvs.gentoo.org:/var/cvsroot"
> cvs -f -d "$CVSROOT" co gentoo-x86/app-admin/rackview

> You can then cd into the directory in question
> (gentoo-x86/app-admin/rackview), and for each file that you want,
> determine the revision of the file just before it was removed (subtract
> 0.1 from the revision shown on the web view, or read the output of `cvs
> log`).

> You can then do `cvs up -r1.X file`, replacing "1.X" with the CVS
> revision and "file" with the filename in question.  

Ah!
OK.

I'll test this out.
post back only if 
it fails.

thx,
James
James
James
James (need to have more lines posted (gmane.org).

[gentoo-user] Re: Attic files (app-admin/rackview) removed?

[James]

Stroller  stellar.eclipse.co.uk> writes:

>> It has been tree-cleansed. ok. So I went to the (gentoo) attic::

> wget
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/
rackview/rackview-0.09-r3.ebuild?revision=1.2
> 
> Doesn't this work for you?

Like I stated before, YES wget works fine. I was fumbaling around with the
cvs syntax/tricks/knowledge and wanted to have that correct. I seem to visit
the attic on a semi regular basis and my /usr/local/portage dir
groweth..


thx,
James

[gentoo-user] Re: Attic files (app-admin/rackview) removed?

[Jonathan Callen]

On 06/07/2016 01:09 PM, James wrote:
> 
> 
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/
>> rackview/?hideattic=0
> 
>>  rackview-0.09-r3.ebuild  seems to have been removed from the attic?
> 
> 
> I have to revert to using 'wget' to snag the files and a copy
> of the latest ebuild. I thought the command string given the the page::
> 
> vs -d :pserver:anonym...@anoncvs.gentoo.org:/var/cvsroot co
> gentoo-x86/app-admin/rackview/files
> 
> was support to download the files and the ebuild, manifest etc etc.?
> 
> Is there a single (anoncvs) command syntax to use, in general to pull
> complete (theoretically compilable) sources from the archive? It's been 
> a while so my cvs could easily be incorrect
> 
> wget is a champ.
> 
> curiously,
> James
> 

Because the entire directory in question is (now) empty, the
requirements are a bit different.

First, you must do the `cvs co` *without* the "-P" flag (check your
~/.cvsrc). You can bypass a ~/.cvsrc by passing "-f" to cvs, like so:

CVSROOT=":pserver:anonym...@anoncvs.gentoo.org:/var/cvsroot"
cvs -f -d "$CVSROOT" co gentoo-x86/app-admin/rackview

You can then cd into the directory in question
(gentoo-x86/app-admin/rackview), and for each file that you want,
determine the revision of the file just before it was removed (subtract
0.1 from the revision shown on the web view, or read the output of `cvs
log`).

You can then do `cvs up -r1.X file`, replacing "1.X" with the CVS
revision and "file" with the filename in question.  Note that CVS
tracked every file separately, so the revisions will differ between files.

-- 
Jonathan Callen



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: Attic files (app-admin/rackview) removed?

[James]

R0b0t1  gmail.com> writes:

>  > man cvs::
>  > Process  directories  recursively.   This is the default for all cvs
>  > commands, with the exception of ls & rls.

>  > So, I have a '/usr/local/portage/app-admin/rackview/' dir.

>  > What is the correct syntax string (I borked this a few times
>  > to no avail)?

> `cd /usr/portage && wget -r $url`
> or
> `wget -P /usr/portage -r $url`



No problems with wget, I was referrring to cvs syntax.

Reread the first email. The problem/question was on cvs syntaxonly.


James

Re: [gentoo-user] Re: Attic files (app-admin/rackview) removed?

[R0b0t1]

On Jun 7, 2016 5:00 PM, "James"  wrote:
>
> R0b0t1  gmail.com> writes:
>
>
> > > vs -d :pserver:anonymous  anoncvs.gentoo.org:/var/cvsroot co
> > > gentoo-x86/app-admin/rackview/files
> > >
> > > was support to download the files and the ebuild, manifest etc etc.?
> > >
> > > Is there a single (anoncvs) command syntax to use, in general to pull
> > > complete (theoretically compilable) sources from the archive? It's
been
> > > a while so my cvs could easily be incorrect
> > >
> > > wget is a champ.
> > >
> > > curiously,
> > > James
> > >
> > Use the recursive option. Save the files to your portage tree.
>
>
> man cvs::
> -R
> Process  directories  recursively.   This is the default for all cvs
> commands, with the exception of ls & rls.
>
> So, I have a '/usr/local/portage/app-admin/rackview/' dir.
>
> What is the correct syntax string (I borked this a few times
> to no avail)?
>
>
> curiously,
> James
> ???
> James
>

`cd /usr/portage && wget -r $url`
or
`wget -P /usr/portage -r $url`
or
`wget --help`

[gentoo-user] Re: Attic files (app-admin/rackview) removed?

[James]

R0b0t1  gmail.com> writes:


> > vs -d :pserver:anonymous  anoncvs.gentoo.org:/var/cvsroot co
> > gentoo-x86/app-admin/rackview/files
> >
> > was support to download the files and the ebuild, manifest etc etc.?
> >
> > Is there a single (anoncvs) command syntax to use, in general to pull
> > complete (theoretically compilable) sources from the archive? It's been
> > a while so my cvs could easily be incorrect
> >
> > wget is a champ.
> >
> > curiously,
> > James
> >
> Use the recursive option. Save the files to your portage tree.
 

man cvs::
-R
Process  directories  recursively.   This is the default for all cvs
commands, with the exception of ls & rls.

So, I have a '/usr/local/portage/app-admin/rackview/' dir.

What is the correct syntax string (I borked this a few times
to no avail)?


curiously,
James
???
James

Re: [gentoo-user] Re: Attic files (app-admin/rackview) removed?

[R0b0t1]

On Jun 7, 2016 12:11 PM, "James"  wrote:
>
> James  tampabay.rr.com> writes:
>
>
> > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/
> > rackview/?hideattic=0
>
> >  rackview-0.09-r3.ebuild  seems to have been removed from the attic?
>
>
> I have to revert to using 'wget' to snag the files and a copy
> of the latest ebuild. I thought the command string given the the page::
>
> vs -d :pserver:anonym...@anoncvs.gentoo.org:/var/cvsroot co
> gentoo-x86/app-admin/rackview/files
>
> was support to download the files and the ebuild, manifest etc etc.?
>
> Is there a single (anoncvs) command syntax to use, in general to pull
> complete (theoretically compilable) sources from the archive? It's been
> a while so my cvs could easily be incorrect
>
> wget is a champ.
>
> curiously,
> James
>

Use the recursive option. Save the files to your portage tree.

[gentoo-user] Re: Attic files (app-admin/rackview) removed?

[James]

James  tampabay.rr.com> writes:


> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/
> rackview/?hideattic=0

>  rackview-0.09-r3.ebuild  seems to have been removed from the attic?


I have to revert to using 'wget' to snag the files and a copy
of the latest ebuild. I thought the command string given the the page::

vs -d :pserver:anonym...@anoncvs.gentoo.org:/var/cvsroot co
gentoo-x86/app-admin/rackview/files

was support to download the files and the ebuild, manifest etc etc.?

Is there a single (anoncvs) command syntax to use, in general to pull
complete (theoretically compilable) sources from the archive? It's been 
a while so my cvs could easily be incorrect

wget is a champ.

curiously,
James

[gentoo-user] Re: Attic (cvs) -> ???(git)

[»Q«]

On Fri, 26 Feb 2016 16:43:05 + (UTC)
James  wrote:

[ about aprospos ]
> Looks like an alias to 'whatis'? 'whereis' still one of my favorite
> little tools.

It queries the whatis database differently depending on how it's called.

  Think of the whatis database as columnar and containing two columns.
  The left column contains the program name (the command used to invoke
  the program) and the right side contains the first line of the
  manual's program synopsis. apropos searches both columns using the
  keyword as a regular expression to find all occurrences of the
  keyword. These occurrences may be embedded in the command word or the
  words of the synopsis. For example, apropos cat returns lines
  containing the word catalog, category, duplicate, application, etc.
  whatis, on the other hand, searches only the left hand column, which
  contains only the program name. This feature is helpful if you know
  the name of a command, but not its function.

That's from , written 20
years ago, but AFAIK these things haven't changed.

[gentoo-user] Re: Attic (cvs) -> ???(git)

[James]

walt  gmail.com> writes:


> Have you noticed that you can find lots of stuff with 'apropos' that
> doesn't actually have a 'man' page?  Here's an example:


# equery belongs apropos
 * Searching for apropos ... 
app-shells/bash-completion-2.1_p20141224-r1
(/usr/share/bash-completion/completions/apropos -> man)
sys-apps/man-db-2.7.5 (/usr/bin/apropos -> whatis)

> # apropos gnutls_x509_crt_export
> gnutls_x509_crt_export (3)  - API function
> gnutls_x509_crt_export2 (3)  - API function

> # man gnutls_x509_crt_export
> No manual entry for gnutls_x509_crt_export

# whatis apropos
apropos (1)  - search the manual page names and descriptions

# whatis whatis
whatis (1)   - display one-line manual page descriptions


Looks like an alias to 'whatis'? 'whereis' still one of my favorite
little tools.

# whereis apropos
apropos: /usr/bin/apropos /usr/share/man/man1/apropos.1.bz2



> Thanks to you and Mike for your examples :)
You've help me far more that I have ever help you:: but, in any case
you are most welcome.


James

[gentoo-user] Re: Attic (cvs) -> ???(git)

[walt]

On Thu, 25 Feb 2016 13:07:34 + (UTC)
James  wrote:

> walt  gmail.com> writes:

> >  Could I trouble you for an example of how you use wget?

> Sure,
> 
> I do it file by file; here is one of the 'files' (patches) I pulled
> down for 'showconsole' now also deprecated:
> 
> wget
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/showconsole/files/1.07-no-TIOCGDEV.patch

> If I know a package is going to be removed, I just emerge it and then
> copy everything to /usr/local/portage//  prior to removal.
> 
> Hit me up with any other questions..

Have you noticed that you can find lots of stuff with 'apropos' that
doesn't actually have a 'man' page?  Here's an example:

# apropos gnutls_x509_crt_export
gnutls_x509_crt_export (3)  - API function
gnutls_x509_crt_export2 (3)  - API function

# man gnutls_x509_crt_export
No manual entry for gnutls_x509_crt_export

Thanks to you and Mike for your examples :)

[gentoo-user] Re: Attic (cvs) -> ???(git)

[James]

Rich Freeman  gentoo.org> writes:


> I used pygit2, but there are a few different implenentations and
> plenty of docs online in general.


Just emerged this one. thx.


> Here is an example program that runs through a history and dumps a
> list of commits and their metadata in csv format:
> https://github.com/rich0/gitvalidate/blob/master/gitdump/parsetrees.py

very nice. I'll have to noodle around a bit with this script and
see what I came up with.



> There are some other scripts that retrieve blobs and manipulate them
> in the same directory.  This was part of the validation of the git
> migration, which uses a map-reduce algorithm to diff every single
> commit in a git history and identify all file revisions (which creates
> a cvs-like per-file history which can then be compared with results
> obtained from parsing a cvs repository for the same information).  The
> only single-threaded step in the process is walking the list of
> commits - all the diffs can be highly paralleled.

There use to be a central repo for many of the common gentoo admin scripts,
any idea where it is now that things have move to github?
(https://code.google.com/archive/p/genscripts/source)

I think there were others. The reason I like those, particularly for
new learning like python, is you get to see good and robust scripting
styles from the gentoo devs. Really helps when learning something new,
even if you have to figure out why things are written in a certain way.


> I doubt you need anything quite so fancy.  As you can see from the
> script pulling metadata out of commits and walking through parents is
> pretty easy.

ipython is some thing I want to learn by experimentation.


> My example doesn't account for merge commits.  There weren't any in
> the cvs->git migration.  Obviously walking commits with merges will
> get a lot messier.

I do not think I need 'merge commits' for one offs, that is pulling
old codes into a development system.  Later on, when I get more aggressive,
pulling old codes to run on gentoo cluster, I might pester the list seeking
more advice.


Thanks for the help, and encouragement,
James

Re: [gentoo-user] Re: Attic (cvs) -> ???(git)

[Rich Freeman]

On Mon, Feb 22, 2016 at 4:49 PM, James  wrote:
> Rich Freeman  gentoo.org> writes:
>
>> If I were doing anything too
>> crazy with all this I'd probably use the python git module.
>
> dev-python/git-python ???   Any others or related docs/howtos/examples?
>

I used pygit2, but there are a few different implenentations and
plenty of docs online in general.

Here is an example program that runs through a history and dumps a
list of commits and their metadata in csv format:
https://github.com/rich0/gitvalidate/blob/master/gitdump/parsetrees.py

There are some other scripts that retrieve blobs and manipulate them
in the same directory.  This was part of the validation of the git
migration, which uses a map-reduce algorithm to diff every single
commit in a git history and identify all file revisions (which creates
a cvs-like per-file history which can then be compared with results
obtained from parsing a cvs repository for the same information).  The
only single-threaded step in the process is walking the list of
commits - all the diffs can be highly paralleled.

I doubt you need anything quite so fancy.  As you can see from the
script pulling metadata out of commits and walking through parents is
pretty easy.

My example doesn't account for merge commits.  There weren't any in
the cvs->git migration.  Obviously walking commits with merges will
get a lot messier.

-- 
Rich

[gentoo-user] Re: Attic (cvs) -> ???(git)

[James]

walt  gmail.com> writes:


> > So using wget to fetch {package/files} from the gentoo attic was/is a
> > reliable exercise to build things removed from the tree, into one's
> > /usr/local/portage tree. It still works

> Hi James.  I need a version of net-libs/gnutls from before the switch
> to git.  Could I trouble you for an example of how you use wget?  So
> far my googling hasn't even revealed the URL of the attic :-/

Sure,


I do it file by file; here is one of the 'files' (patches) I pulled down for
'showconsole' now also deprecated:

wget
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/showconsole/files/1.07-no-TIOCGDEV.patch


> Thanks for any hints.


If I know a package is going to be removed, I just emerge it and then copy
everything to /usr/local/portage//  prior to removal.

Hit me up with any other questions..


hth,
James

Re: [gentoo-user] Re: Attic (cvs) -> ???(git)

[Mike Gilbert]

On Wed, Feb 24, 2016 at 9:21 PM, walt  wrote:
> On Mon, 22 Feb 2016 19:49:22 + (UTC)
> James  wrote:
>
>> So using wget to fetch {package/files} from the gentoo attic was/is a
>> reliable exercise to build things removed from the tree, into one's
>> /usr/local/portage tree. It still works
>
> Hi James.  I need a version of net-libs/gnutls from before the switch
> to git.  Could I trouble you for an example of how you use wget?  So
> far my googling hasn't even revealed the URL of the attic :-/


https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/?hideattic=0

[gentoo-user] Re: Attic (cvs) -> ???(git)

[walt]

On Mon, 22 Feb 2016 19:49:22 + (UTC)
James  wrote:

> So using wget to fetch {package/files} from the gentoo attic was/is a
> reliable exercise to build things removed from the tree, into one's
> /usr/local/portage tree. It still works

Hi James.  I need a version of net-libs/gnutls from before the switch
to git.  Could I trouble you for an example of how you use wget?  So
far my googling hasn't even revealed the URL of the attic :-/

Thanks for any hints.

[gentoo-user] Re: Attic (cvs) -> ???(git)

[James]

Rich Freeman  gentoo.org> writes:


> The way I'd do it is run "git log --diff-filter=D --summary" and
> search for multimon.  That gives you the commit ID it was removed in.
> Then you want to checkout the commit before it.

This seems very reasonable and systematic. I'm not trying for git_voodo,
just a logical way to restore from archives the last/latest version
of a given package on a system. Sure, Later on I'll create my own github
and push up the package and any new /files/ (patches) that are needed
as I maintain them. Rote methodologoy is what I think I want and is
needed as a general pathway for anyone that may have need of an old
package.

> 
> In this case doing that search will yield:
> commit 760e17fcbac1b8c04a96ab08306dbcc644131dfb
> Author: Pacho Ramos  gentoo.org>
> Date:   Sat Feb 20 12:49:31 2016
> 
> Remove masked for removal packages
> 
> ...
>  delete mode 100644 app-misc/multimon/Manifest
>  delete mode 100644 app-misc/multimon/files/multimon-1.0-flags.patch
>  delete mode 100644 app-misc/multimon/files/multimon-1.0-includes.patch
>  delete mode 100644 app-misc/multimon/files/multimon-1.0-prll.patch
>  delete mode 100644 app-misc/multimon/metadata.xml
>  delete mode 100644 app-misc/multimon/multimon-1.0-r2.ebuild
>  delete mode 100644 app-misc/multimon/multimon-1.0-r3.ebuild
> ...
> 
> Then what you want to do is checkout the previous commit:
> git checkout "760e17fcbac1b8c04a96ab08306dbcc644131dfb^1"
> 
> Now you're looking at the repo containing the last known state of
> those files, so you can just copy them or cat them from the directory
> tree:
> cat app-misc/multimon/multimon-1.0-r3.ebuild
> 
> You could build all that into a script. 


Exactly my plan. Once I do a few of these manually, script it up. 

> If I were doing anything too
> crazy with all this I'd probably use the python git module. 


dev-python/git-python ???   Any others or related docs/howtos/examples?




> Then you'll get all your query results in collections and such instead of
> having to parse all that output.  If you do want to parse you can
> control the output of git log.

> I will say that deleted files are one of those things that isn't as
> pretty in git.   

Yep, from what I've read. Going back in time to find minor patches or
extraneous sources can be an adventure, with any system. Git pitfalls will
have some fun with me, for a while.


> It isn't like a file with a deleted state flag that
> you can search by - they're identified by their presence in one commit
> and absence in the next.  In fact, to identify them I'd think that
> git-log has to basically has to diff every tree for every commit
> historically.  That isn't as bad as it sounds as each directory is
> shared with the previous commit COW-style - so if only one
> subdirectory contains changes only that directory needs to be walked
> to find what those differences are, and so on.  The structure of our
> repository leads to a relatively well-balanced tree with fairly few
> levels, which is a good case for git.  When I did the git validation I
> had to walk all of it and doing it smartly in parallel you can get it
> done remarkably quickly even in python (considering we have 2M
> commits, which is 2M* files you could have to
> diff in the brute force approach).


Since I'll be doing this rather frequently (I use the cvs attic
extensively), I'll post up some (ugly) python  code for suggestions.

Ultimately, this will be fun to on a gentoo cluster using ipython?


Thanks for the input!
James