On Mon, 26 Jan 2009, Jeff King wrote:
> 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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
