[gentoo-dev] Bisecting Was: Referencing bug reports in git

[Duncan]

hasufell posted on Tue, 11 Aug 2015 13:58:20 +0200 as excerpted:

> In addition, we just took the freedom to add the clause "all commits
> must be repoman-valid":
> https://wiki.gentoo.org/index.php?
title=Gentoo_git_workflow&diff=352978&oldid=352858
>
> That will be necessary too for the CI work mgorny is doing and will also
> make bisecting and cherry-picking easier.

The mention of bisect got me thinking... I'm not exactly sure I'm wording 
this right, but hopefully the question is clear enough...

What are the practical implications of and reasons for doing a bisect, on 
a package-tree repo, where it's typically the out-of-tree package sources 
where most functionality-bisection would happen, and in-tree commits tend 
to result in atomic package updates, or at least atomic USE flag, etc, 
changes on a package?

The typical reason for a bisect is to find the commit where a bug 
originated, but that's upstream package/project bisects.  I don't quite 
see how that maps to distro package tree repo bisects, as it seems to me 
there's nothing really to bisect -- problems should be with specific 
package versions or with USE flag or similar changes within an ebuild/
eclass, and it seems to me that's known along with awareness of the 
problem in the first place, leaving no reason to bisect to find the 
problem.

Tho arguably eclass change issues are an exception, and bisectable in the 
usual sense for the usual purpose.  Actually, that could make 
troubleshooting eclass updates MUCH simpler than it was before.  Luckily, 
at least I as a user didn't end up with too many direct eclass issues to 
troubleshoot.

Tho I can definitely think of a non-traditional use for bisect.  While I 
update my workstation more or less weekly, I updated my 32-bit 
netbook[1]  far less frequently, every year or two.  It occurs to me that 
using git bisect to automate working out the resulting update issues 
might be far easier than some of the manual tricks and workaround I used 
to end up doing, to finally get an updated to current, working system 
once again.  Bisect start, immediately declare bisect bad, inner looping 
until I got to about a three-month update, update to it, bisect reset, 
outer-looping on the bisect to another 3-4 month update... until I was 
caught up.  Of course one can't go back past our current switch to git, 
but in five years, one could in theory pull the old laptop out that was 
last updated yesterday, and roll back gentoo's now five-years-future tree 
four years and nine months, and start the update process, ultimately 
bringing it upto date without starting with a new stage tarball install, 
as would have been the only really feasible pre-git alternative for a 
five-year-outdated system.  Not that a new stage tarball wouldn't be 
faster after five years in any case, but at least the incremental update-
in-place should now be possible.

---
[1] 32-bit netbook: Now gone and not yet replaced, but I intend to get 
another, tho amd64 this time so I can mostly build once for both, one for 
three if I setup an amd64-based router as I intend to as well, and 
hopefully avoid the year-plus update period issue as I can just binpkg-
update after the first one.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman