RE: git with custom diff for commits

["Gerald Gutierrez" <ggmlfs@gmail.com>]

 
> -----Original Message-----
> From: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de] 
> Sent: Tuesday, December 18, 2007 1:27 PM
> To: Gerald Gutierrez
> Cc: 'Junio C Hamano'; 'Matthieu Moy'; git@vger.kernel.org
> Subject: RE: git with custom diff for commits
> 
> Hi,
> 
> On Tue, 18 Dec 2007, Gerald Gutierrez wrote:
> 
> > Yes, but wouldn't it be slick to actually teach git's 
> internal diff to 
> > do things like GNU diff can, like the ignore option -I, case 
> > insensitivity, etc. I thought that's what the external diff 
> capability 
> > is for, but it is not so.
> 
> I disagree.  Your statement is misleading when you say you 
> want the internal diff to do things like GNU diff can.
> 
> What you want to do _in fact_ is not only modify the diff 
> _output_, but the commit _input_.
> 
> And I am not so keen on such filters.  If I do not want to 
> commit,  I do not change it to begin with.  Yes, your 
> mysqldump is a special case here.  
> But it is special anyway, as it is not source code.

I don't understand how it is a benefit to have "git commit" and "git diff"
do different diff functions. It confuses me. A scenario: I keep doing git
diff's and it says there is no difference, but then git commit keeps telling
me there is.

While I understand it was built for the kernel and everybody likes the plain
text format, it is not a stretch of the imagination to have files that are
semantically identical but have byte-wise differences. OpenDocument files,
image files, XML, etc. Cases can be made either way that "the same" means
semantically or byte-wise. It's perfectly fine that the default is
byte-wise. But, if the user takes the time to build a custom diff, then
wouldn't it be reasonable to assume that user means for git to do semantic
comparisons for diff, commit and other git functions, even if there are
inconsequential byte-wise differences in the file itself?

Gerald.