From: Michael J Gruber <git@drmicha.warpmail.net>
To: Jeff King <peff@peff.net>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>, git@vger.kernel.org
Subject: Re: [PATCH 0/4] Don't warn about missing EOL for symlinks
Date: Thu, 03 Jun 2010 21:55:58 +0200 [thread overview]
Message-ID: <4C0808CE.2000506@drmicha.warpmail.net> (raw)
In-Reply-To: <20100603170724.GB22779@coredump.intra.peff.net>
Jeff King venit, vidit, dixit 03.06.2010 19:07:
> On Thu, Jun 03, 2010 at 04:57:44PM +0200, Michael J Gruber wrote:
>
>> May I kindly direct you to the next parts you cut out, especially the
>> one talking about "described thorougly along with the
>> rationale in 3/4", and to the commit message of 3/4? :)
>>
>> I'm not breaking existing tests, of course, which also test
>> format-patch/apply cycles with symlinks.
>
> Yes, but you are breaking "git diff | git apply", aren't you? It is
We don't have any tests for that then. I ran all tests with my patch.
> already broken with textconv, but that is a new feature that people opt
> into by using it. Symlink patches are a feature that has worked fine
> until now with the above command.
>
> 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.
...which is why you need to use diff --no-textconv for scripting, which
is why I use that to decide about the symlink warnings!
One could introduce a separate config for that, of course, if you mind
unguarded diff|apply. But don't you think that those "No newline"
warnings are just plain stupid for symlinks?
Michael
next prev parent reply other threads:[~2010-06-03 19:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-03 14:35 [PATCH 0/4] Don't warn about missing EOL for symlinks Michael J Gruber
2010-06-03 14:35 ` [PATCH 1/4] diff/xdiff: refactor EOF-EOL detection Michael J Gruber
2010-06-03 21:58 ` Junio C Hamano
2010-06-04 7:38 ` Michael J Gruber
2010-06-05 6:38 ` Junio C Hamano
2010-06-05 18:58 ` Michael J Gruber
2010-06-06 22:03 ` Jeff King
2010-06-06 4:00 ` Junio C Hamano
2010-06-06 9:01 ` Johannes Sixt
2010-06-06 22:08 ` Jeff King
2010-06-07 8:10 ` Michael J Gruber
2010-06-03 14:35 ` [PATCH 2/4] diff: make treatment of missing EOL at EOF configurable Michael J Gruber
2010-06-03 14:35 ` [PATCH 3/4] diff: Do not warn about missing EOL at EOF for symlinks Michael J Gruber
2010-06-03 17:02 ` Jeff King
2010-06-03 14:35 ` [PATCH 4/4] RFC: add whitespace rule for no-eol-at-eof Michael J Gruber
2010-06-03 14:47 ` [PATCH 0/4] Don't warn about missing EOL for symlinks Matthieu Moy
2010-06-03 14:57 ` Michael J Gruber
2010-06-03 17:07 ` Jeff King
2010-06-03 19:55 ` Michael J Gruber [this message]
2010-06-03 20:17 ` Jeff King
2010-06-04 14:15 ` Johannes Sixt
2010-06-04 15:25 ` 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=4C0808CE.2000506@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=Matthieu.Moy@grenoble-inp.fr \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.