Squared Financial IT wrote: > If you have added entries to .gitignore outside its "managed by > etckeeper" section, they are lost upon uninit, as uninit naively > deletes the whole file. This is in contrast to update-ignore > behaviour, which afaics carefully only munges the "managed by etckeeper" > section. IMHO etckeeper should be more careful upon uninit, and only nuke > the "managed by etckeeper" section rather than the whole file - > at least if the .gitignore has entries outside the managed section.
I agree with this change in principle. If you'd like to develop a patch, I will probably commit it. The code run by update-ignore could be reused with slight changes to delete, rather than updating the content. > Hmm. I wonder would .git/info/exclude be an alternative for > etckeeper to manage, and reserve .gitignore to the user. Maybe not though, > after all you can't check in .git/info/exclude but you can check in > .gitignore, and you might want to do that even if etckeeper is > auto-managing it, to preserve the history of changes to its > auto-management... A good idea, but one reason not to do that is users may want to override etckeeper's default ignores. Currently they can remove the "managed by etckeeper" part and update-ignore will not change the file any more. Also, not all version control systems will have an equivilant to git's .git/info/exclude. -- see shy jo
signature.asc
Description: Digital signature
