Re: [bug-patch] [PATCH] use di-set module rather than hash: easier-to-use, more efficient

[Jim Meyering]

Andreas Gruenbacher wrote:
>> Here's that same patch, rebased, and with two small additions:
>>   - update gnulib to the latest, to get di-set
>>   - add to m4/.gitignore
>>
>> Any objection?
>
> This looks reasonable.
>
> One of the things I would soon like to fix is to make --dry-run work for
> patches which modify the same file twice (bug 25860) which will require to
> keep the intermediary results around.

My first reaction was "why?", since it seems like supporting this
fringe use case would induce disproportionately large changes in patch.
It sounds like it would have to involve creating a temporary file
for each and every affected file, just in case some later patch
happens to affect one of those just-patched files.  Then you'd
have to ensure that an interrupted (or exiting) patch always removes
all of its temporary files.  But if they're created via tmpfile, that's
not an issue (though portably determining what directory/partition
such a temporary file resides in is hard -- and that makes properly
diagnosing failure hard, too: you can say only "disk full" or
"I/O error" but not where).  If you choose mkstemp, then you do
have to worry about clean-up.

An alternative to writing every patched file would be to
read and analyze the entire patch file first, and to identify
which files are patched more than once, but that would involve
major redesign and is generally undesirable (there may not be
enough memory to read the entire patch into memory).

My take: it's not worth it.  Patch far too hairy already.
I suggest simply to detect that case and give a diagnostic.

> Another is to fix git-style criss-cross
> renames (bug 31058); this will require to keep the original files around.
>
> My initial idea was to switch to a name based cache instead of the device /
> inode number based cache as part of that, but maybe there is a better way.

I haven't looked at that yet.