On Fri, Dec 28, 2018 at 4:46 PM H. Peter Anvin <hpa@xxxxxxxxx> wrote: > > 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. It's been discussed, see [1] and others in the same thread. The feeling I got was it seemed good idea, but we're just not sure about the exact syntax and some corner cases, and most importantly nobody has stepped up to implement it. [1] https://public-inbox.org/git/20181109101918.GC7410@xxxxxxxxxxxxxxxxxxxxx/ -- Duy
