Re: [PATCH 01/13] dir: allow exclusions from blob in addition to file

> Jeff Hostetler <git@jeffhostetler.com> writes:
> 
>> The existing code handles use cases where you want to read the
>> exclusion list from a pathname in the worktree -- or from blob
>> named in the index when the pathname is not populated (presumably
>> because of the skip-worktree bit).
>>
>> I was wanting to add a more general case (and perhaps my commit
>> message should be improved).  I want to be able to read it from
>> a blob not necessarily associated with the current commit or
>> not necessarily available on the local client, but yet known to
>> exist.
> 
> Oh, I understand the above two paragraphs perfectly well, and I
> agree with you that such a helper to read from an arbitrary blob is
> a worthy thing to have.  I was merely commenting on the fact that
> such a helper that is meant to be able to handle more general cases
> is not used to help the more specific case that we already have,
> which was a bit curious.
> 
> I guess the reason why it is not done is (besides expediency)
> because the model the new helper operates in would not fit well with
> the existing logic flow, where everything is loaded into core
> (either from the filesystem or from a blob) and then a common code
> parses and registers; the helper wants to do the reading (only) from
> the blob, the parsing and the registration all by itself, so there
> is not much that can be shared even if the existing code wanted to
> reuse what the helper offers.
> 
> The new helper mimicks the read_skip_worktree_file_from_index()
> codepath to massage the data it reads from the blob to buf[] but not
> really (e.g. even though it copies and pastes a lot, it forgets to
> call skip_utf8_bom(), for example).  We may still want to see if we
> can share more so that we do not have to worry about these tiny
> differences between codepaths.

> 
>> With my "add_excludes_from_blob_to_list()", we can request a
>> blob-ish expression, such as "master:enlistments/foo".  In my
>> later commits associated with clone and fetch, we can use this
>> mechanism to let the client ask the server to filter using the
>> blob associated with this blob-ish.  If the client has the blob
>> (such as during a later fetch) and can resolve it, then it can
>> and send the server the OID, but it can also send the blob-ish
>> to the server and let it resolve it.
> 
> Security-minded people may want to keep an eye or two open for these
> later patches---extended SHA-1 expressions is a new attack surface
> we would want to carefully polish and protect.
>