Re: binary search debugging of compilers

On 2023-05-17, Russ Cox <rsc@swtch.com> wrote:
> because BitKeeper history is a lattice, not a straight line. So your
> test points became


That's one reason I religiously keep git histories linear, though
they could be lattices also, like in BK.


I've not used the "git merge" command since 2009, other than by accident
(via git pull, having forgotten to reconfigure pull to do rebase rather
than merge). And not even that; I quickly trained myself never to run
"git pull"; I banished that command also. Always "git fetch" and then
"git rebase". Before rebasing, I usually take a look at the diverging
upstream: how much new is coming in, and what it's like.


I really, really hate the whole concept of a commit having more than one
parent.


> From: Brian Ness <bcn@bubblecreek.com>
> than relocatables. Cray had its own version control system called USM
> (Unicos Source Manager) which had support for atomic changes, meaning
> that a set of related changes in multiple files could be encapsulated
> and treated as a single thing. We called those atomic change sets,
> “mods”. As far as I know, there were no other version control systems
> supporting that at the time.


Simple archives of a snapshot of the entire source code support
mods, though obviously in an unwieldy way when the code is large;
and if you want every change isolated, that requires keeping a lot
of archives.


(And that's basically what git is: every commit in git is snapshot
rather than a delta.)


Linux kernel people used to bisect with kernel snapshots, before
they settled on a version control system.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Return to the comp.compilers page.
Search the comp.compilers archives again.