1 |
Rich Freeman <rich0 <at> gentoo.org> writes: |
2 |
|
3 |
|
4 |
> The way I'd do it is run "git log --diff-filter=D --summary" and |
5 |
> search for multimon. That gives you the commit ID it was removed in. |
6 |
> Then you want to checkout the commit before it. |
7 |
|
8 |
This seems very reasonable and systematic. I'm not trying for git_voodo, |
9 |
just a logical way to restore from archives the last/latest version |
10 |
of a given package on a system. Sure, Later on I'll create my own github |
11 |
and push up the package and any new /files/ (patches) that are needed |
12 |
as I maintain them. Rote methodologoy is what I think I want and is |
13 |
needed as a general pathway for anyone that may have need of an old |
14 |
package. |
15 |
|
16 |
> |
17 |
> In this case doing that search will yield: |
18 |
> commit 760e17fcbac1b8c04a96ab08306dbcc644131dfb |
19 |
> Author: Pacho Ramos <pacho <at> gentoo.org> |
20 |
> Date: Sat Feb 20 12:49:31 2016 |
21 |
> |
22 |
> Remove masked for removal packages |
23 |
> |
24 |
> ... |
25 |
> delete mode 100644 app-misc/multimon/Manifest |
26 |
> delete mode 100644 app-misc/multimon/files/multimon-1.0-flags.patch |
27 |
> delete mode 100644 app-misc/multimon/files/multimon-1.0-includes.patch |
28 |
> delete mode 100644 app-misc/multimon/files/multimon-1.0-prll.patch |
29 |
> delete mode 100644 app-misc/multimon/metadata.xml |
30 |
> delete mode 100644 app-misc/multimon/multimon-1.0-r2.ebuild |
31 |
> delete mode 100644 app-misc/multimon/multimon-1.0-r3.ebuild |
32 |
> ... |
33 |
> |
34 |
> Then what you want to do is checkout the previous commit: |
35 |
> git checkout "760e17fcbac1b8c04a96ab08306dbcc644131dfb^1" |
36 |
> |
37 |
> Now you're looking at the repo containing the last known state of |
38 |
> those files, so you can just copy them or cat them from the directory |
39 |
> tree: |
40 |
> cat app-misc/multimon/multimon-1.0-r3.ebuild |
41 |
> |
42 |
> You could build all that into a script. |
43 |
|
44 |
|
45 |
Exactly my plan. Once I do a few of these manually, script it up. |
46 |
|
47 |
> If I were doing anything too |
48 |
> crazy with all this I'd probably use the python git module. |
49 |
|
50 |
|
51 |
dev-python/git-python ??? Any others or related docs/howtos/examples? |
52 |
|
53 |
|
54 |
|
55 |
|
56 |
> Then you'll get all your query results in collections and such instead of |
57 |
> having to parse all that output. If you do want to parse you can |
58 |
> control the output of git log. |
59 |
|
60 |
> I will say that deleted files are one of those things that isn't as |
61 |
> pretty in git. |
62 |
|
63 |
Yep, from what I've read. Going back in time to find minor patches or |
64 |
extraneous sources can be an adventure, with any system. Git pitfalls will |
65 |
have some fun with me, for a while..... |
66 |
|
67 |
|
68 |
> It isn't like a file with a deleted state flag that |
69 |
> you can search by - they're identified by their presence in one commit |
70 |
> and absence in the next. In fact, to identify them I'd think that |
71 |
> git-log has to basically has to diff every tree for every commit |
72 |
> historically. That isn't as bad as it sounds as each directory is |
73 |
> shared with the previous commit COW-style - so if only one |
74 |
> subdirectory contains changes only that directory needs to be walked |
75 |
> to find what those differences are, and so on. The structure of our |
76 |
> repository leads to a relatively well-balanced tree with fairly few |
77 |
> levels, which is a good case for git. When I did the git validation I |
78 |
> had to walk all of it and doing it smartly in parallel you can get it |
79 |
> done remarkably quickly even in python (considering we have 2M |
80 |
> commits, which is 2M*<num-files-in-portage> files you could have to |
81 |
> diff in the brute force approach). |
82 |
|
83 |
|
84 |
Since I'll be doing this rather frequently (I use the cvs attic |
85 |
extensively), I'll post up some (ugly) python code for suggestions. |
86 |
|
87 |
Ultimately, this will be fun to on a gentoo cluster using ipython? |
88 |
|
89 |
|
90 |
Thanks for the input! |
91 |
James |