Hi, On Sun, 3 Mar 2019, SZEDER Gábor wrote: > On Sat, Mar 02, 2019 at 01:19:44PM -0800, Johannes Schindelin via GitGitGadget wrote: > > The --stress option currently accepts an argument, but it is confusing > > to at least this user that the argument does not define the maximal > > number of stress iterations, but instead the number of jobs to run in > > parallel per stress iteration. > > Well, these options' description in 't/README' is quite clear on what > they do. If the lack of updates to 't/README' in these patches is any > indication, then you haven't read that :) but doing so might very well > have avoided your confusion in the first place. Yep, hadn't read it, assumed that it was obvious that `--stress=<N>` meant: try for at most <N> times to replicate the issue. Which to me is a good indicator that the UI could be improved... > According to my Bash history, I used '--stress=<even-more-cpu-cores>' > about 20x more often than '--stress-limit=<N>'. That's not surprising > at all, since the main point is to try to trigger rare, hard to > reproduce failures, no matter how many repetitions it takes. And even > if there is an upper bound, it is usually not the number of repetitions > I know in advance, but rather the time I'm willing to sacrifice on it, > e.g. how long I'm on lunch break or doing groceries, or when I need my > CPUs for more important things, or simply when I give up, and hit > ctrl-C. I don't doubt that *you* need `--stress-jobs=<N>` more often than `--stress-limit=<N>`, but I really think that common users will need the latter a lot more often (if they need the former at all). > And with --stress-jobs=<N> I will have to type more :) Sorry ;-) Ciao, Dscho
