On 10/25/2017 2:43 AM, Junio C Hamano wrote:
Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> writes:+static int add_excludes_from_buffer(char *buf, size_t size, + const char *base, int baselen, + struct exclude_list *el); + /* * Given a file with name "fname", read it (either from disk, or from * an index if 'istate' is non-null), parse it and store the @@ -754,9 +758,9 @@ static int add_excludes(const char *fname, const char *base, int baselen, struct sha1_stat *sha1_stat) { struct stat st; - int fd, i, lineno = 1; + int fd; size_t size = 0; - char *buf, *entry; + char *buf;fd = open(fname, O_RDONLY);if (fd < 0 || fstat(fd, &st) < 0) {The post-context of this hunk is quite interesting in that there is a call to read_skip_worktree_file_from_index(); which essentially pretends as if we read from the filesystem but in fact it grabs the blob object name registered in the index and reads from it. The reason why it is interesting is because this patch adds yet nother "let's instead read from a blob object" function and there is no sign to make the existing one take advantage of the new function seen in this patch.
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. I'm thinking of the case the client could ask the server to do a partial clone using a sparse-checkout specification stored in a well-known location on the server. The reason for this is that, in this case, the client is pre-clone and doesn't have a worktree or index. 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. Jeff
