On Thu, Aug 09, 2018 at 01:04:43PM +0200, Bartosz Konikiewicz wrote: > Hi there! > > I hope that the subject of my message (i.e. the question) is > exhaustive enough, so I'll just stick to reproducing my issue. > > Steps to reproduce: > > 1. Create a new file. > 2. Stage the file. > 3. Add the file to .gitignore. > 4. Stage the .gitignore. > 5. Commit changes. > > I imagined that the file would now be removed from the stage (because > it's ignored now and not yet committed) but it isn't. Where this > behavior would be desirable? I know that a 'git add' command can be > invoked with an '-f' flag, which would yield the same result, but I > can't come up with an explanation where can it be applied. As far as I know, that is not an intentionally supported workflow. It is merely the result that .gitignore is only considered when adding new files to the index, not when committing nor when updating the entry for an existing file. If you are asking as a more general case: why do we not complain about .gitignore for files the index already knows about, then I think that is useful. It lets you override the .gitignore _once_ when adding the file initially, and then you don't have to deal with it again (and keep in mind that the pattern excluding it may be broad, like "*.o", or even just "*", so simply deleting it from the .gitignore is not an option). You could probably accomplish this these days by using a negative pattern in your .gitignore file. But I think the behavior in question may predate negative patterns (but I didn't dig). It's also a bit simpler to use in practice, IMHO. -Peff
