Christian Brabandt cbli...@256bit.org writes:
And here is the second one.
Wow, great and so fast! I really apologize it.
No need to apologize, but appreciating would not hurt ;-)
Thanks for an interesting idea. I spotted a buglet in 1/2 so I'll
queue a fixed version on 'pu' when I push
Hi Junio!
On Di, 26 Mai 2015, Junio C Hamano wrote:
No need to apologize, but appreciating would not hurt ;-)
Right. Thanks.
Best,
Christian
--
Trägt der Bauer rote Socken, will er seinen Bullen schocken.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
Christian Brabandt cbli...@256bit.org writes:
But as I said in the other message, I think that the approach this
patch takes goes in a wrong direction. Instead of adding a single
check and highlight this and only kind of breakage on preimage
option as a new kind to existing what kind of use
Hi Junio!
On Di, 26 Mai 2015, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
I'll send out two patch series to do the painting part (I didn't
want to touch --check, as its utility is even more dubious
compared to painting, at least to me).
And here is the second one.
Hi Junio!
On Mo, 25 Mai 2015, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
I like this idea.
I don't.
My use case is determining whether a patch to a pristine-tar
repository introduced trailing whitespace (which is not okay) or
just left it there
Hi Junio!
On Mo, 25 Mai 2015, Junio C Hamano wrote:
Christian Brabandt cbli...@256bit.org, Christian Brabandt
c...@256bit.org writes:
As far as I can see, this does not break any tests and also the
behaviour of git-diff --check does not change.
Even if this change introduced a bug
Christian Brabandt cbli...@256bit.org writes:
It was the one I am interesting in and also the one that I usually try
to avoid ;)
(In fact, I thought if the other options would be needed, one could add
additional suboptions for core.whitespace as well,...
That road leads to madness. Why
Junio C Hamano gits...@pobox.com writes:
I'll send out two patch series to do the painting part (I didn't
want to touch --check, as its utility is even more dubious
compared to painting, at least to me).
And here is the second one.
-- 8 --
Subject: [PATCH 2/2] diff.c: --ws-check-deleted
Christian Brabandt cbli...@256bit.org, Christian Brabandt
c...@256bit.org writes:
As far as I can see, this does not break any tests and also the
behaviour of git-diff --check does not change.
Even if this change introduced a bug that changed the behaviour
(e.g. say, exited with failure
Currently git-diff only highlights trailing whitespace in the new lines
(prefixed with '+'), thus it is not visible in the deleted lines
(prefixed with '-').
Therefore introduce a new configuration variable for the core.whitespace
setting blank-at-eol-old (default off) that will highlight
On Mon, May 25, 2015 at 04:27:40PM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
My use case is determining whether a patch to a pristine-tar
repository introduced trailing whitespace (which is not okay) or
just left it there (which is okay).
In your
brian m. carlson sand...@crustytoothpaste.net writes:
I like this idea.
I don't.
My use case is determining whether a patch to a pristine-tar
repository introduced trailing whitespace (which is not okay) or
just left it there (which is okay).
In your use case, where keeping trailing blank
On Mon, May 25, 2015 at 11:11:34PM +0200, Christian Brabandt wrote:
Here is my use case: I have been working in a team repository,
reformatting the source and wondered, why my reformatting did introduce
some trailing whitespace. I suspected a bug in Vim and started to debug
it, until I found
13 matches
Mail list logo
