Rich Freeman <rich0 <at> 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 <pacho <at> 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*<num-files-in-portage> 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
