Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: >> When "test_subcommand_inexact git pack-objects" is run, the printf >> assigns to $expr: >> >> expr='"git".*"pack-objects".*' >> >> and the actual grep command invoked becomes >> >> grep '"event":"child_start".*\["git".*"pack-objects".*\]' >> >> I am not sure if that is what we really want. > > Ah, yes this certainly seems to not be the expected plan. It does > allow for more flexibility than intended: the intention was to > add flexibility at the end of the command, but instead adds > flexibility throughout, only caring that a certain list of options > is present as a subsequence (except that the first item is the > first item, namely "git" in most cases). I guess I sent a response before reading this message from you. > That unintended flexibility would allow the current needs to use > > test_subcommand_inexact ! git fetch > > as desired, but there is the additional worries about whether it > is too flexible for the existing uses. Yeah, it looked a bit too loose. > If you think that we should fix the helper to work differently, then > I can work on a patch to do so, so Abhradeep doesn't get too > sidetracked on that. I agree that comparing what _inexact does and what its inventor wanted it to do and reconciling the differences would be outside the scope of this topic, which means the test in this patch should refrain from using the _inexact helper at all. I found it quite a roundabout way to look into trace to see if a "fetch" was run to determine if we are doing the right thing. Regardless of whatever mechanism is used to lazily fetch objects that have become necessary from the promisor remotes, what we want to ensure is that the blob object HEAD:new-file.txt is still missing in our object store after running "log --follow", isn't it? In a future version of "git", our on-demand lazy fetch mechanism may not even invoke "git fetch" under the hood, after all. Don't we have a more direct way to ask "does this object exist in our object store, or is it merely left as a promise?" without triggering a lazy fetching that we can use in this test? I think such a direct approach is what we want to use in this test.
