1 |
On Wed, Aug 12, 2015 at 07:20:54AM +0000, Duncan wrote: |
2 |
> hasufell posted on Tue, 11 Aug 2015 13:58:20 +0200 as excerpted: |
3 |
> |
4 |
> > In addition, we just took the freedom to add the clause "all commits |
5 |
> > must be repoman-valid": |
6 |
> > https://wiki.gentoo.org/index.php? |
7 |
> title=Gentoo_git_workflow&diff=352978&oldid=352858 |
8 |
> > |
9 |
> > That will be necessary too for the CI work mgorny is doing and will also |
10 |
> > make bisecting and cherry-picking easier. |
11 |
> |
12 |
> The mention of bisect got me thinking... I'm not exactly sure I'm wording |
13 |
> this right, but hopefully the question is clear enough... |
14 |
> |
15 |
> What are the practical implications of and reasons for doing a bisect, on |
16 |
> a package-tree repo, where it's typically the out-of-tree package sources |
17 |
> where most functionality-bisection would happen, and in-tree commits tend |
18 |
> to result in atomic package updates, or at least atomic USE flag, etc, |
19 |
> changes on a package? |
20 |
> |
21 |
> The typical reason for a bisect is to find the commit where a bug |
22 |
> originated, but that's upstream package/project bisects. I don't quite |
23 |
> see how that maps to distro package tree repo bisects, as it seems to me |
24 |
> there's nothing really to bisect -- problems should be with specific |
25 |
> package versions or with USE flag or similar changes within an ebuild/ |
26 |
> eclass, and it seems to me that's known along with awareness of the |
27 |
> problem in the first place, leaving no reason to bisect to find the |
28 |
> problem. |
29 |
> |
30 |
> Tho arguably eclass change issues are an exception, and bisectable in the |
31 |
> usual sense for the usual purpose. Actually, that could make |
32 |
> troubleshooting eclass updates MUCH simpler than it was before. Luckily, |
33 |
> at least I as a user didn't end up with too many direct eclass issues to |
34 |
> troubleshoot. |
35 |
|
36 |
I agree that bisecting would typically not happen that often because |
37 |
usually you'd just emerge =cat/pkg-1.2.3 but there are times when |
38 |
updates are done without a revbump that might have broken something so |
39 |
it could be useful. Also eclasses would definitely be useful. There are |
40 |
a few useful cases when it might make things easier but probably rare, |
41 |
tho its good to have the tool available in case. |
42 |
|
43 |
> Tho I can definitely think of a non-traditional use for bisect. While I |
44 |
> update my workstation more or less weekly, I updated my 32-bit |
45 |
> netbook[1] far less frequently, every year or two. It occurs to me that |
46 |
> using git bisect to automate working out the resulting update issues |
47 |
> might be far easier than some of the manual tricks and workaround I used |
48 |
> to end up doing, to finally get an updated to current, working system |
49 |
> once again. Bisect start, immediately declare bisect bad, inner looping |
50 |
> until I got to about a three-month update, update to it, bisect reset, |
51 |
> outer-looping on the bisect to another 3-4 month update... until I was |
52 |
> caught up. Of course one can't go back past our current switch to git, |
53 |
> but in five years, one could in theory pull the old laptop out that was |
54 |
> last updated yesterday, and roll back gentoo's now five-years-future tree |
55 |
> four years and nine months, and start the update process, ultimately |
56 |
> bringing it upto date without starting with a new stage tarball install, |
57 |
> as would have been the only really feasible pre-git alternative for a |
58 |
> five-year-outdated system. Not that a new stage tarball wouldn't be |
59 |
> faster after five years in any case, but at least the incremental update- |
60 |
> in-place should now be possible. |
61 |
|
62 |
I like the idea, but its probably easier to just |
63 |
git checkout $(git rev-list -n 1 --before="2015-12-01 12:00" master) |
64 |
and then you just change the date a month at a time or something |
65 |
|
66 |
-- Jason |
67 |
|
68 |
> --- |
69 |
> [1] 32-bit netbook: Now gone and not yet replaced, but I intend to get |
70 |
> another, tho amd64 this time so I can mostly build once for both, one for |
71 |
> three if I setup an amd64-based router as I intend to as well, and |
72 |
> hopefully avoid the year-plus update period issue as I can just binpkg- |
73 |
> update after the first one. |
74 |
> |
75 |
> -- |
76 |
> Duncan - List replies preferred. No HTML msgs. |
77 |
> "Every nonfree program has a lord, a master -- |
78 |
> and if you use the program, he is your master." Richard Stallman |
79 |
> |
80 |
> |