Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Also, about the commit IDs. As long as the tests are consistent (i.e. they > use test_commit rather than plain `git commit`, or at least call > `test_tick` beforehand), the commit IDs should actually be identical > between runs and not depend on the time of day or the date. > > The only exception to that rule is when some previous test cases call > `test_commit` but are guarded behind some prereq and may not be executed > at all. In that case, the precise commit IDs depend on the particular set > of active prereqs.
Good observation. The tests written such a way may make later introduction of new hash function troublesome, though (we already have tons of them, and it is already a hassle just imagining that we will have to migrate them X-<). And what you gave below is an excellent suggestion to even solve that future headaches. > But as far as I can tell, t3420 does not have any test cases guarded by > prereqs. > > Taking an additional step back, I wonder whether we have to hard-code the > commit IDs (or XXX) to begin with. Why not generate the `expect` files > with the information at hand? We can simply ask `git rev-parse --short`. > > For the stash's commit ID, there is no record in the ref space, of course > (because it was created with `git stash create`). But I think in this > case, it is legitimate to simply grep the output. > > That way, the test would be precise and resilient. > > So for example instead of adding the t/t3420/expected-success-am verbatim, > you could generate the output via > > cat >expect <<-EOF > $(grep "^Created autostash: [0-9a-f][0-9a-f]*\\$" output) > HEAD is now at $(git rev-parse --short HEAD~2) third commit > First, rewinding head to replay your work on top of it... > Applying: second commit > Applying: third commit > Applied autostash. > EOF > > Ciao, > Johannes
