Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"

From: Keith Cascio <keith@cs.ucla.edu>
Date: Jan 27, 2009, 03:01 UTC
Message-ID: <alpine.GSO.2.00.0901261749230.16158@kiwi.cs.ucla.edu>
In-Reply-To: <20090126115957.GA20558@coredump.intra.peff.net>

On Mon, 26 Jan 2009, Jeff King wrote:

Show 7 quoted lines

> Yep, that's what defaults are. And guess what: we _already_ have the same 
> thing. I have diff.renames set in my ~/.gitconfig. That does _exactly_ what
> 
>   git config --global diff.primer -M
> 
> would do. It's just a syntax that saves us from having to introduce a boatload 
> of new variables, one per command line option.

Great point, IOW, primer magnifies already existing pitfalls. I like that about primer v1, however unsatisfying it is otherwise. Rather than stick a piece of chewing gum in that chink in the dam, let's repair it and get the whole darn thing ready for the 21st century while we're at it.

Show 13 quoted lines

> However, there are two other drawbacks of aliases that I can think of:
>   1. They are tied to a specific command, whereas diff options are tied
>      to the concept of diffing. So now I have to write an alias (with a
>      new name) for each command:
>        git config alias.mylog 'log -w'
>        git config alias.mydiff 'diff -w'
>        git config alias.myshow 'show -w'
>   2. They can't change defaults based on the file to be diffed. One of
>      the things Keith mentioned (and I don't remember if this was
>      implemented in his patch series) was supporting this for
>      gitattributes diff drivers. How do I do
>        git config diff.tex.primer -w
>      using aliases?

This scenario was specifically part of my motivation for imagining primer v1 as I did.

> But now you have me defending Keith's proposal

And well.

> which he should be doing himself ;P

True. I'm at the point here where I will demand of myself one of two outcomes. Either I:

(1) Satisfy myself on a deep, foundational level why the inescapable structure of not just this particularly well-constituted software project (Git!), but software projects in general, since surely many a fearless development team has braved this philosophical sticky place before us, prevents one from getting everything one wants, i.e. forces a compromise, a.k.a. the "no silver bullet" interpretation.

(2) Write primer patch v2 that somehow does THE RIGHT THING, also satisfying on a deep level to at least myself, a.k.a. the silver bullet.

                                            -- Keith