Ævar Arnfjörð Bjarmason wrote: > On Thu, Aug 5, 2010 at 11:09, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> git checkout side && >> echo same line | append_cr >>file && >> echo same line >>control_file && >> git add file control_file && >> + test_tick && >> git commit -m "add line from b" && >> git tag b && > > FWIW this looks like it could use Dmitry's "test-lib.sh: introduce 4th > argument to test_commit() specifying a tag name" patch. In this example I am not confident the file has content suitable for echo. The discussion brings to mind something[1] I thought wise in a different context: “I mentioned earlier that UNIX was not especially suited to applications involving vast quantities of data. The reason is this: files are limited in size to 64K bytes. The reason for this is not particularly defensible, but it has to do with the fact that the PDP-11 word size is 16 bits. There are a couple of ways around this problem. One of them is simply to split one large logical file into several smaller actual files. This approach works for a while. The limitation here comes from the fact that directories are searched in a linear fashion. Thus if the are a vast number of files, it can become quite time-consuming tosearch directories to find the files they contain. We have not noticed this to be a problem, so far, it is only a worry. Another way around the small file size is to use a disk as a special file. For various reasons, when an entire disk drive is accessed as a special file, the size limitation does not occur. Thus one can set up a program which manages its own data-- in effect is its own, special-purpose file system-- and expect reasonable results. This again bears on the general versus special purpose system: it probably is more efficient anyway to do your own data management, provided the extra labor is worth the cost.” Of course the tradeoffs are completely different here but it is worth bearing in mind the underlying process: sometimes a too general facility only gets in the way unless all the facets of how it should be used have been carefully understood (i.e., good interfaces sometimes evolve by excluding the special cases until the missed benefit from not including them is overwhelming). Sorry for the ramble. Another way to say it: I am happy to see test_commit be made more useful, but if extra-weird cases do not fit it, please do not take that as a failing. [1] http://cm.bell-labs.com/cm/cs/who/dmr/notes.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html