Re: RFE: version-controlled merge rules
- Date: Fri, 28 Dec 2018 17:03:40 +0100
- From: Duy Nguyen <pclouds@xxxxxxxxx>
- Subject: Re: RFE: version-controlled merge rules
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  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  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.