Hi Martin,
On 01/03/2020 15:59, Martin Ågren wrote:
But I also wonder if we even need the "bar" commit. Similarly,
"--detach"-ing when checking out master seems unnecessary, unless we're
afraid of "messing up" master, by modifying the expectations of later
tests? Was that something you were concerned about?
The "bar" commit was present in the test I based mine on, where it was
equally unnecessary except possibly for making the test easier to
understand. I have no feelings whether it is better to have it in or
leave it out, other than that it should be consistent across tests.
Not messing up the master branch is what multiple tests in this file,
specifically the test I based mine on, do. If the test I had based mine
on and my test had both done
echo aaa >bar &&
git add bar &&
git commit -m bar_commit
on the master branch, whichever test appeared second would fail, because
git commit would not detect any modifications. This seems needlessly
fragile to me, so I agree with the pattern used by the existing tests.
I realize the test you add is similar to the ones surrounding it. But it
does look tempting to squash in the diff below. The test still fails
before and passes after. What do you think about this? Does this
correctly capture your scenario?
Yeah, the test set up is literally a copy of the test immediately above,
except modified not to use conflicting ref names.
It could be simplified, but in that case, the other tests should be
simplified the same way, and I did not think it was appropriate to make
such changes here.
Cheers,
Harald van Dijk