{"thread":{"id":"55037","subject":"gitattributes filter: add new %r that expands to repository root","startedAt":"2021-01-23T16:21:17Z","lastAt":"2021-01-23T16:21:17Z","messageCount":1,"participants":["Calum McConnell"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"415070","messageId":"508da412f239180b3cbfff4f676cc0072d04cd93.camel@gmail.com","threadId":"55037","inReplyTo":null,"subject":"gitattributes filter: add new %r that expands to repository root","fromName":"Calum McConnell","fromEmail":"calumlikesapplepie@gmail.com","sentAt":"2021-01-22T17:11:25Z","receivedAt":"2021-01-23T16:21:17Z","isPatch":false,"sender":{"key":"calumlikesapplepie@gmail.com","avatar":null},"body":"Dear Git Maintainers,\n\nWhen building content filters with gitattributes, for instance to ensure\ngit stores the plain-text rather than the binary form of data in certain\nformats, it is often advantageous to separate the filters into separate\nscripts.  However, as the $PWD where content filters are executed is\nunspecified (at least, unspecified in the git documentation I could find),\nso the path to scripts needs to be specified as an absolute path.  That\nmeans that the guide for setting up a repository which uses scripts to\nfilter content cannot simply consist of \"copy-paste the following lines to\nyour .git/config file\", and it means that the otherwise safe operation of\nmoving a git repository from one folder to another is decidedly unsafe.\n\nTo fix this, I propose the addition of a \"%r\" sequence, similar to the\nexisting \"%f\", which expands to the repository root (as opposed to the\npath of the file undergoing filtering).  This would enable calls to\ncontent filter scripts to be (for instance) stored in a root /scripts\nfolder, and the git-config value to be \"sh %r/scripts/erase-all-secret-\nplots\".  If backwards compatibility is a serious concern, the sequence\ncould only be expanded if it occurs at the beginning of the first two\nwords.\n\nI believe that would be simple to implement, and would be willing to do so\nmyself, but wanted to get your views first.  \n\nAnother useful addition, but one that would be less simple to implement\nwould be the creation of a way for a set of default keys to be added to\nall repositories that clone from a certain remote.  This could take the\nform of a .gitconfig-defaultkeys file in the root of the repository, which\nis appended to .git/config on clone, if there are core structural reasons\nthat prevent a configuration file (even one with a restricted set of\npermitted keys) from being included in the tracked repository itself.\n\nThis is my first message to the git mailing list, so apologies if I\ndid/said something wrong/stupid/obvious! Please give me feedback.\n\nThank you,\nCalum McConnell\n\n"}]}