Date: Fri, 17 Apr 2020 07:52:53 -0700
From: Jason Thorpe <thor...@me.com>
Message-ID: <7e54033f-9f14-4db3-a11a-01d63cd92...@me.com>
| The New Hotness (which isn't particularly new, at this point)
| is to create branches and merge what you want into that branch.
What I don't understand, is how this single commit-id works in practice
(not how it is generated, I mean how it is used). Say you've got some
local changes you're testing, maybe some ARM device driver (or related
stuff), and I have local changes as well (maybe some new sh code - I
actually have a lot of that, though most of it is no longer "new" and
quite possibly none of it will appear in public) - so we're both working
from different states of the overall tree. Hence different ID's right?
Now imagine that while testing, some schedueller bug causes a panic,
or the ATF tests detect some (unrelated to both of us) failure that
shouldn't be happening (perhaps rump was neglected in someone's
changes from elsewhere, yet again).
If we both, along with someone running a pristine tree, all see this
failure, perhaps manifesting in slightly different ways, how do we
all determine that we're running the same versions of all of the
relevant files, and hence are probably all seeing the same bug?
Currently, with each file having its own version identfifier, it
is easy, but if everything is to share one single "it is this version"
ID, how can we know that we are all actually running the same version
of whatever code broke and is affecting all of us?
kre
