On 12/27/18 3:55 PM, Jonathan Nieder wrote: > Hi, > > H. Peter Anvin wrote: > >> [merge "version"] >> name = Version file merge driver >> driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A > [...] >> However, I can't even put this in .gitattributes, because doing so would break >> any user who *doesn't* have the previous rule defined locally. Even worse, if >> this rule needs to change, propagating it to all new users has to be done >> manually... never mind if it needs to vary by branch! >> >> The simplest way to address this would presumably be to let the >> repository/working directory contain a .gitconfig file that can contain rules >> like that. (Allowing it to be in the repository proper is probably a >> requirement for merges to be handled correctly on bare repositories; I'm not >> sure how .gitattributes is handled for that.) > > The main issue I see is that this would make it a little *too* easy to > run arbitrary code on the user's machine. Build systems often already > lead to that, but users are more familiar with the risks for build > than for version control. > > See [1] for some related discussion. > > That said, using the include.path feature (see git-config(1)), it's > possible to do something similar: > > [include] > path = ../.gitconfig > > Thanks and hope that helps, > Jonathan > That would be great, except that it doesn't work if the worktree isn't in "..". This is one of many cases where it would be great to have environment variable interpolation. -hpa
