Re: [PATCH 01/12] t6038 (merge.renormalize): style nitpicks

[Jonathan Nieder <jrnieder@gmail.com>]

Ævar Arnfjörð Bjarmason wrote:
> On Thu, Aug 5, 2010 at 11:09, Jonathan Nieder <jrnieder@gmail.com> 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