1 |
On Mon, Feb 22, 2016 at 2:49 PM, James <wireless@×××××××××××.com> wrote: |
2 |
> |
3 |
> So using wget to fetch {package/files} from the gentoo attic was/is a reliable |
4 |
> exercise to build things removed from the tree, into one's |
5 |
> /usr/local/portage tree. It still works, but I'm guessing there is a now a |
6 |
> "github_way" to do this. |
7 |
|
8 |
cvs was file-oriented, and git is not, so I'll warn you up-front that |
9 |
finding deleted files is a bit of pita. |
10 |
|
11 |
> A Fully automated script? I could not find a |
12 |
> gentoo wiki page to such effect, nor any other suggested pathway, but surely |
13 |
> it exists? I guessing the gentoo's cvs_attic is deprecated now and thus |
14 |
> subject to removal in the near future? |
15 |
|
16 |
I don't think anybody has plans to get rid of the old cvs, but nothing |
17 |
new goes into it, so it is frozen in time as of the migration date. |
18 |
|
19 |
> I'd would be excited to see a specific example, using git on on of the |
20 |
> recently removed packages "app-misc/multimon" [1], which was just removed |
21 |
> from the portage tree, unless someone wants to use another example. That |
22 |
> package is about radio packets. |
23 |
|
24 |
The approach to take depends on whether you want to find EVERYTHING |
25 |
that has ever been deleted, or a specific thing, but ultimately it |
26 |
comes down to looking at the full log. Lots of good stuff can be |
27 |
found here: |
28 |
https://stackoverflow.com/questions/953481/find-and-restore-a-deleted-file-in-a-git-repository |
29 |
|
30 |
The way I'd do it is run "git log --diff-filter=D --summary" and |
31 |
search for multimon. That gives you the commit ID it was removed in. |
32 |
Then you want to checkout the commit before it. |
33 |
|
34 |
In this case doing that search will yield: |
35 |
commit 760e17fcbac1b8c04a96ab08306dbcc644131dfb |
36 |
Author: Pacho Ramos <pacho@g.o> |
37 |
Date: Sat Feb 20 12:49:31 2016 |
38 |
|
39 |
Remove masked for removal packages |
40 |
|
41 |
... |
42 |
delete mode 100644 app-misc/multimon/Manifest |
43 |
delete mode 100644 app-misc/multimon/files/multimon-1.0-flags.patch |
44 |
delete mode 100644 app-misc/multimon/files/multimon-1.0-includes.patch |
45 |
delete mode 100644 app-misc/multimon/files/multimon-1.0-prll.patch |
46 |
delete mode 100644 app-misc/multimon/metadata.xml |
47 |
delete mode 100644 app-misc/multimon/multimon-1.0-r2.ebuild |
48 |
delete mode 100644 app-misc/multimon/multimon-1.0-r3.ebuild |
49 |
... |
50 |
|
51 |
Then what you want to do is checkout the previous commit: |
52 |
git checkout "760e17fcbac1b8c04a96ab08306dbcc644131dfb^1" |
53 |
|
54 |
Now you're looking at the repo containing the last known state of |
55 |
those files, so you can just copy them or cat them from the directory |
56 |
tree: |
57 |
cat app-misc/multimon/multimon-1.0-r3.ebuild |
58 |
|
59 |
You could build all that into a script. If I were doing anything too |
60 |
crazy with all this I'd probably use the python git module. Then |
61 |
you'll get all your query results in collections and such instead of |
62 |
having to parse all that output. If you do want to parse you can |
63 |
control the output of git log. |
64 |
|
65 |
I will say that deleted files are one of those things that isn't as |
66 |
pretty in git. It isn't like a file with a deleted state flag that |
67 |
you can search by - they're identified by their presence in one commit |
68 |
and absence in the next. In fact, to identify them I'd think that |
69 |
git-log has to basically has to diff every tree for every commit |
70 |
historically. That isn't as bad as it sounds as each directory is |
71 |
shared with the previous commit COW-style - so if only one |
72 |
subdirectory contains changes only that directory needs to be walked |
73 |
to find what those differences are, and so on. The structure of our |
74 |
repository leads to a relatively well-balanced tree with fairly few |
75 |
levels, which is a good case for git. When I did the git validation I |
76 |
had to walk all of it and doing it smartly in parallel you can get it |
77 |
done remarkably quickly even in python (considering we have 2M |
78 |
commits, which is 2M*<num-files-in-portage> files you could have to |
79 |
diff in the brute force approach). |
80 |
|
81 |
-- |
82 |
Rich |