From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Keith Cascio <keith@CS.UCLA.EDU>
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
git@vger.kernel.org
Subject: Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
Date: Sun, 25 Jan 2009 20:30:05 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.1.00.0901252016590.14855@racer> (raw)
In-Reply-To: <alpine.GSO.2.00.0901251033160.12651@kiwi.cs.ucla.edu>
Hi,
On Sun, 25 Jan 2009, Keith Cascio wrote:
> On Sun, 25 Jan 2009, Johannes Schindelin wrote:
>
> > That would break existing scripts using "git diff" rather badly. We
> > already did not allow something like "git config alias.diff ..." from
> > changing the behavior of "git diff", so I cannot find a reason why we
> > should let diff.primer (a misnomer BTW) override the behavior.
>
> I took special care to protect all core scripts from the effects.
What about my scripts I have here locally? Do you want to change them,
too?
> I fact, by introducing the cpp macro DIFF_MACHINE_FRIENDLY() and the
> command-line options "--machine-friendly" and "--no-primer", I made such
> protection declarative. Don't you find it preferable that existing
> programs and scripts would explicitly declare their desire for
> machine-friendly output?
No. We made a promise long time ago that plumbing (and "git diff" is
pretty much plumbing, except for the configurable colorness) would not
change behind scripts' backs.
And since Shawn uses plumbing for that very reason, your diff.primer patch
would not be allowed to make a difference. Ever.
Now, if you would have changed only the UI diff things (i.e. git diff, but
not git diff-files), I could have accepted the diff.primer patch for
different applications than "git gui", but from cursory reading of your
patch it does not appear so.
Speaking of appearance (or for that matter, explaining why it was only a
cursory reading): did it not occur to you that your coding style is
utterly different from the surrounding code?
Just to number a few things that would definitely prohibit this patch from
being applied:
- space instead of tabs,
- horrible lengths of spaces within the line,
- no space after if, but after the parenthesis.
Now, this could be good explanation why you need the patch (to ignore
white-space), but that is not a reason of letting us suffer, too.
Besides, it seems you did a lot of "fixes" on the side that I do not like
at all. Simple example: if the original code cleared the
DIRSTAT_CUMULATIVE flag, it is not acceptable for you to introduce an
unnecessary if(), testing if the CUMULATIVE flag was set to begin with.
Ciao,
Dscho
next prev parent reply other threads:[~2009-01-25 19:34 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 [this message]
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
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.DEB.1.00.0901252016590.14855@racer \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=keith@CS.UCLA.EDU \
--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