Hi, Jeff King wrote: > Bartosz Konikiewicz wrote: >> 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. [...] > 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. I am not sure I agree with "not intentionally supported". It's a little closer to "logical consequence of some intentionally features", because: > 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). This workflow is very common. > 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. Agreed about simpler, even though it's not part of any of my own habits. In retrospect, despite the precedent of cvsignore, calling the file .gitignore may not have been a great idea. Some other name that conveys .git-prevent-me-from-accidentally-adding-these-files would make the behavior less surprising to new users. "git help gitignore" has some notes about this. If you have ideas about moments in interactive use where we could print some messages to make the behavior less surprising, that would be very welcome. Thanks, Jonathan
