From: Keith Cascio <keith@CS.UCLA.EDU>
To: Jeff King <peff@peff.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
Date: Mon, 26 Jan 2009 19:01:33 -0800 (PST) [thread overview]
Message-ID: <alpine.GSO.2.00.0901261749230.16158@kiwi.cs.ucla.edu> (raw)
In-Reply-To: <20090126115957.GA20558@coredump.intra.peff.net>
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
next prev parent reply other threads:[~2009-01-27 3:03 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-25 17:30 [PATCH v1 0/3] Introduce config variable "diff.primer" Keith Cascio
2009-01-25 17:30 ` [PATCH v1 1/3] " Keith Cascio
2009-01-25 17:30 ` [PATCH v1 2/3] Test functionality of new " Keith Cascio
2009-01-25 17:30 ` [PATCH v1 3/3] git-gui hooks for " Keith Cascio
2009-01-25 18:22 ` Johannes Schindelin
2009-01-25 18:58 ` Keith Cascio
2009-01-25 18:17 ` [PATCH v1 1/3] Introduce " Johannes Schindelin
2009-01-25 18:44 ` Keith Cascio
2009-01-25 19:30 ` Johannes Schindelin
2009-01-25 20:14 ` Keith Cascio
2009-01-25 22:11 ` Jeff King
2009-01-25 22:58 ` Keith Cascio
2009-01-25 23:25 ` Jeff King
2009-01-25 20:34 ` Junio C Hamano
2009-01-26 2:30 ` Junio C Hamano
2009-01-26 2:37 ` Keith Cascio
2009-01-26 3:18 ` Jeff King
2009-01-26 3:38 ` Junio C Hamano
2009-01-26 2:40 ` Keith Cascio
2009-01-26 3:12 ` Jeff King
2009-01-26 3:42 ` Junio C Hamano
2009-01-26 3:45 ` Jeff King
2009-01-26 10:54 ` Johannes Schindelin
2009-01-26 11:06 ` Jeff King
2009-01-26 10:59 ` backwards compatibility, was " Johannes Schindelin
2009-01-26 11:16 ` Jeff King
2009-01-26 11:28 ` Johannes Schindelin
2009-01-26 11:59 ` Jeff King
2009-01-27 3:01 ` Keith Cascio [this message]
2009-01-26 15:29 ` Jay Soffian
2009-01-26 18:48 ` Jeff King
2009-01-26 19:49 ` Jay Soffian
2009-01-26 20:04 ` Junio C Hamano
2009-01-26 20:32 ` Jay Soffian
2009-01-26 20:35 ` Jeff King
2009-01-26 3:36 ` Junio C Hamano
2009-01-25 20:35 ` [PATCH v1 0/3] " Junio C Hamano
2009-01-25 20:41 ` Keith Cascio
2009-01-25 22:07 ` Jeff King
2009-01-27 1:47 ` Keith Cascio
2009-01-27 4:54 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.GSO.2.00.0901261749230.16158@kiwi.cs.ucla.edu \
--to=keith@cs.ucla.edu \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).