Hi Bjoern, On Tue, Oct 14, 2014 at 10:51:32AM +0200, Bjoern Michaelsen <bjoern.michaelsen@canonical.com> wrote:
Well, I see a good reason for that. I recently saw some bibisects being done with Mikloss dbgutils bibisect repo[1] and they seem to contain more "git bisect skip"s than everything else leading to less than optimal results.
As explained in the wiki page, for me, a dbgutil bibisect repo is more useful than a product one (it's ~zero effort to build it, as I'm just populating it with builds I already have), but in other scenarios the normal one (i.e. what you produce) is more useful. It's just an accident that nobody currently maintains a bibisect repo that hosts product builds. Even if such a configure option would be added, I would not use it for my builds, as it does not help me, as a developer. ;-)
BTW, it seems to me that Mikloss repo does have the source-hash-deadcodedeadcodedeadcodedeadcode tag that my repos have[2] and thus make it impossible to identify what a bibisect means without downloading/updating that whole bibisect repo from the stuff that people copy-paste to bugzilla. Is that so, and if so, can it be changed?
Quoting its README: 'Exact git source hash of the current build is the SHA1 in the first line of build-info.txt.' So it's the same as yours, just you need to do 'git show $sha1:build-info.txt', not 'git show $sha1' if you want to get core.git hashes. The reason is that in the past it happened that after a 'git pull -r' I did have an accidental not-yet-pushed commit, and this way if such an error occurs, then the build is not completely useless: if the sha1 is not valid, you can just jump to the next one, and so on. This trick is not necessary in your situation when you have a build farm, producing builds after the fact. :-) Regards, Miklos
Attachment:
signature.asc
Description: Digital signature