Re: [PATCH 0/4] Don't warn about missing EOL for symlinks

From: Jeff King <peff@peff.net>
Date: Jun 4, 2010, 15:25 UTC
Message-ID: <20100604152519.GA22844@sigill.intra.peff.net>
In-Reply-To: <4C090A84.20209@kdbg.org>

On Fri, Jun 04, 2010 at 04:15:32PM +0200, Johannes Sixt wrote:

Show 9 quoted lines

> Am 03.06.2010 19:07, schrieb Jeff King:
> >I don't think "but they should be using plumbing to generate patches"
> >is the right answer, either. Yes, we expect the diff porcelain to behave
> >differently depending on configuration, but with the exception of
> >textconv, it always produces an actual applicable patch.
> 
> I don't by into that argument: You have to give --binary if you have
> changes in binary files. With Michael's patch, you have to give
> --no-textonv (too). I'm in favor of the patch.

OK, I'll accept that "git diff | git apply" does have some special cases which need to be considered. But every special case is a possible place for users to make a mistake. So we have to consider whether adding another one is worthwhile. Specifically:

  1. Are symlinks as unusual an occurrence as binary files? Do users
     perceive them as different enough from regular text files that they
     will remember to use special command line options?

  2. Traditionally, symlinks have not been such a special case. Is a
     behavior change between versions worth it?

I am not necessarily against the patch. I'm just trying to think through all of the possible negative ramifications. I think I would prefer the approach to treat it like color (do it only when requested explicitly, or when outputting to a terminal or pager).

-Peff