> But you don't want to do this anyway: you want to use 'git bisect',
> which is designed for this sort of binary-searching for bugs with
> unknown origin. (Note that after every 'git bisect good/bad' you will
> need to do a 'git submodule update' to bring the submodules up to date
> properly.)

Thank you for the explanation.

Like 'git reset --hard', seems every explanation I read is focused on a repo for a single product/package and not a multi-layered repo like Trinity. As I mentioned in a previous mail, the Trinity repo is really 134 (or so) repos, or 134 products. Whereas I can easily 'git reset --hard' or 'git bisect' an individual Trinity package/module, I can't easily bisect the entire Trinity source tree. At least, I am not seeing how to do this.

The particular regression (bug reports 1111 and 178) I am helping debug involves several Trinity packages. That is, at least tdelibs and k3b are involved, probably tdebase too. Yet tdelibs affects all packages. The regression might have been introduced in the many commits with the new TDEHW libs, which includes tdebase. Any reset or bisect of tdelibs or tdebase likely requires all dependent packages to be reset/bisected too.

The challenge is that Trinity packages are all interrelated. Proper testing requires all packages be rebuilt the same as they were on the same date.

For me to troubleshoot by building packages from a specific date requires me to reset (bisect) many Trinity modules, possibly all.

At this point nobody yet knows when this regression started because the particular feature is not something everybody uses every day. Just today, we discovered the bug is masked when used through NFS shares, hence a previous leaning the problem was distro specific or PEBKAC.

Based upon the bug report dates, the regression appeared some time before the middle of July. A package set I found in my backups from March 27 does not exhibit the regression, but based upon the recent news about NFS masking, I should retest those packages without that layer.

I don't mind the work involved with rebuilding packages, testing, etc. I just am not seeing how to get there because of the complex relationship of all Trinity packages. :(

I might start storing tarball snapshots each time I re-sync my local tree and then always build only from tarballs rather than my local GIT tree. For sure I'm going to become more rigorous about archiving package sets, which would allow faster testing of regressions.

Darrell