Hi Jakub and Junio, On Mon, Dec 30, 2019 at 03:27:45PM -0800, Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > > > Denton Liu <liu.denton@xxxxxxxxx> writes: > > > >> In one case, we were using a redirection operator to feed input into > >> sed. However, since sed is capable of opening its own files, make sed > >> open its own files instead of redirecting input into it. > > > > Could you please write in the commit message what advantages does this > > change bring? > > A fair question. > > My version of short answer is "nothing---it is not wrong to write it > either way, and it is not worth the patch churn to rewrite it from > one form to the other, once the script is written". In one of my earliest contributions to Git, Gábor suggested that since since 'head' and 'sed' can open its own input file, there's no need to redirect its standard input[1]. I assumed that letting these programs open their own input was one of those minor "style cleanup" things that was done such as removing spaces after redirection operators, indenting compound command blocks, etc. Whenever I've been cleaning tests up, if I noticed a `sed <` in the area, I'd apply the transformation as a style cleanup. I guess the only tangible benefit I can think of is that programs which have a file open can optimise on the fact that they can perform random access on the file whereas with stdin, only linear access is allowed. I don't know enough about the internals of various seds to be able to comment on whether any of them actually take advantage of this, however. Anyway, if no one else feels strongly about this, I can drop this patch and I'll stop doing this cleanup in the future. Thanks, Denton [1]: https://lore.kernel.org/git/20190317130539.GA23160@xxxxxxxxxx/
