Re: Multi-OS Emacs buildbot?

[Tim Landscheidt]

Pankaj Jangid <pankaj@codeisgreat.org> wrote:

> […]

>> (NB: Strictly speaking, this only works when the
>> failure is, eh, monotonous (?), i. e. the build worked for
>> all commits from last-good to the-one-before-first-failure
>> and failed for all commits from first-failure to now.)

> My use-case is very simple. I pull and make bootstrap daily. And on some
> odd day if the build breaks, I want to file a bug. If I have the
> information which commit broke it then it helps the maintainers. Even if
> the failure is monotonous (not sure what to call linear may be), that
> may help in narrowing down the issue. It could be inaccurate but still.

> […]

Git records the changes to the local repository in a refer-
ence log.  One can access that with "git reflog" and/or "git
rev-parse".  (For example:

| [tim@passepartout ~/src/emacs]$ git rev-parse 'HEAD'
| 2d790c6c57b244447390c023679752243e0049c9
| [tim@passepartout ~/src/emacs]$ git rev-parse 'HEAD@{one.week.ago}'
| 2d790c6c57b244447390c023679752243e0049c9
| [tim@passepartout ~/src/emacs]$ git rev-parse 'HEAD@{two.week.ago}'
| 67a8bdb90c9b5865b7f17290c7135b1a5458c36d
| [tim@passepartout ~/src/emacs]$

suggests that I last fetched the Emacs repository some time
between one and two weeks ago.)

So, untested, if you encounter a bug in HEAD, you could
start the bisection, mark that commit as "bad", then iterate
over HEAD@{1}, HEAD@{2}, etc. marking failures as "bad" com-
mits as you go along, until you find a working commit, mark
that as "good", and then start "git bisect run".

(I hope it is clear that I'm not advocating against using CI
systems; I just want to point out how one can narrow down a
bug if either a repository does not have a CI system attach-
ed or the CI system was not configured to track a particular
bug.)

Tim