Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> + # Make master incompatible with up/master >> + git reset --hard HEAD^ && >> + # Add a new branch >> + git branch atomic && >> + # --atomic should roll back creation of up/atomic >> + test_must_fail git push --atomic "$up" master atomic && >> + git ls-remote "$up" >up-remotes && >> + test_must_fail grep atomic up-remotes > > Why not `test_must_fail git -C "$d" rev-parse refs/heads/atomic`? They check different expectations. Between making sure that the state observable in the resulting repository matches what should have been left and checking what the command says it did to its output, I agree that the former is a more robust way to test the commands. We obviously could test both, though ;-)