Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.compilers > #3472

Re: binary search debugging of compilers

Show all headers | View raw

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

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: binary search debugging of compilers Russ Cox <rsc@swtch.com> - 2023-05-17 10:55 -0400
  Re: binary search debugging of compilers Cameron McInally <cameron.mcinally@nyu.edu> - 2023-05-17 13:40 -0400
  Re: binary search debugging of compilers Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-17 18:47 +0000
  Re: binary search debugging of compilers Spiros Bousbouras <spibou@gmail.com> - 2023-05-18 10:50 +0000
    Re: binary search debugging of compilers Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-19 03:44 +0000
    binary search debugging of compilers Cliff Click <cclick0@gmail.com> - 2023-05-19 10:47 -0700
  Re: binary search debugging of compilers mrs@kithrup.com (Mike Stump) - 2023-05-20 18:04 +0000

csiph-web