On 6/4/2020 8:56 PM, Junio C Hamano wrote: > Derrick Stolee <stolee@xxxxxxxxx> writes: > >> The first is due to the .gitignore syntax. The syntax allows exact >> matches for _directories_ using a trailing slash "/". For example, >> we can match everything in A/B/C with the pattern >> >> A/B/C/ >> >> This would match the files in A/B/C/ and its subdirectories, but will >> not match a file A/B/C.txt or A/B/C1/. There is no equivalent matching >> for files, so A/B/C _will_ match a file A/B/C and A/B/C.txt. Whether this >> matters to you or not depends on your file structure. > > The pattern A/B/C _will_ match a file A/B/C and a directory A/B/C/, > but I do not think it matches a file A/B/C.txt (or a path with any > other suffix). You are correct! I am mistaken. The directory/file confusion would lead to some interesting logic in an implementation that allowed file matches. > I suspect that for the purpose of your explanation, the pattern > A/B/C does not have to match A/B/C.txt to cause trouble; the fact > that it matches directory A/B/C would be sufficient, I guess. Yes. It certainly complicates things. The thing I neglected to mention is that this file-based matching is usually necessary when there is a directory containing _all_ of the "big files" instead of organizing those files into directories based on who needs those files. It is possible to reorganize the directory structure to use cone mode and achieve similar goals. Thanks, -Stolee
