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 mess
Christian Brabandt 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 today's intergratio
Hi Junio!
On Di, 26 Mai 2015, Junio C Hamano wrote:
> Junio C Hamano 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.
Wow,
Junio C Hamano 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 option
Traditio
Christian Brabandt 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 of white
Christian Brabandt 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 should we add 2
Hi Junio!
On Mo, 25 Mai 2015, Junio C Hamano wrote:
> Christian Brabandt , Christian Brabandt
> 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
Hi Junio!
On Mo, 25 Mai 2015, Junio C Hamano wrote:
> "brian m. carlson" 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).
Christian Brabandt , Christian Brabandt
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 status code when only preimage had
e
On Mon, May 25, 2015 at 04:27:40PM -0700, Junio C Hamano wrote:
> "brian m. carlson" 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 use case, where ke
"brian m. carlson" 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 that is otherwise not
O
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 foun
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 traili
13 matches
Mail list logo
