From: Jeff King Date: Fri, 26 Oct 2018 09:36:44 GMT Subject: Re: the opposite of .gitignore, whitelist Message-ID: <20181026093644.GA20876@sigill.intra.peff.net> In-Reply-To: On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote: > On 10/25/18 1:37 AM, Junio C Hamano wrote: > > "lhf635@163.com" writes: > > > >> I have a good idea, add a file to git that is the opposite of .gitignore..., > > Do negative patterns in .gitignore file help without inventing > > anything new? > I did this several years ago in an attempt to track /etc/ (minus > ownership, of course) without storing secrets in the git history.  As > the system grew and was maintained (read: crap added), the negative > patterns grew untenable.  I quickly realized it wasn't the correct way > to solve the problem. > > Unfortunately, shortly after realizing this, I left that project.  So I > never had the chance to develop a proper solution.  However, the concept > of a '.gitonly' file was exactly was I was seeking.  So, for what it's > worth, I've definitely had at least one legit usecase for this feature. > > The usecases tend to center around tracking select files within the > rootfs of a full-blown operating system.  Or a subset thereof. I think what Junio meant is to ignore everything by default, like: echo '*' >.gitignore and then selectively use negative patterns (and being in .gitignore, that makes them positive "yes, include this") to add things back: echo 'foo' >>.gitignore which ends up being roughly the same as your .gitonly concept. I don't offhand remember if you might run into problems where a subdirectory is ignored by the "*" and we do not even recurse into it. I think it would work OK as long as you put everything in the top-level gitignore, like: echo 'subdir/file' >>.gitignore but I didn't test. -Peff