From: James Coglan
In 04005834ed ("log: fix coloring of certain octopus merge shapes",
2018-09-01) there is a fix for the coloring of dashes following an
octopus merge. It makes a distinction between the case where all parents
introduce a new column, versus the case where the fi
From: James Coglan
In 04005834ed ("log: fix coloring of certain octopus merge shapes",
2018-09-01) there is a fix for the coloring of dashes following an
octopus merge. It makes a distinction between the case where all parents
introduce a new column, versus the case where the fi
eff.net/
and it looks great. Probably because it's the same as your test cases --
the "non-collapsing type" I called it there (or maybe it's all just the
out-of-order thing James brought up; I don't recall discussing that
before, but certainly his test case exhibits the same off-by-one
coloring weirdness without the code change).
-Peff
On Thu, Oct 10, 2019 at 11:16:24AM -0700, Denton Liu wrote:
> You can see the results of this by doing:
>
> $ git fetch https://github.com/Denton-L/git.git testing/graph-output
> $ git diff FETCH_HEAD^2 t/t4214-log-graph-octopus.sh
>
> and the resulting diff is very pleasing imo.
I g
Hi James,
Nicely done! This issue was bugging me for a while!
On Thu, Oct 10, 2019 at 09:13:52AM -0700, James Coglan via GitGitGadget wrote:
[...]
> diff --git a/t/t4214-log-graph-octopus.sh b/t/t4214-log-graph-octopus.sh
> index 9ada687628..fbd485d83a 100755
> --- a/t/t4214-log-graph-octopus.s
From: James Coglan
In 04005834ed ("log: fix coloring of certain octopus merge shapes",
2018-09-01) there is a fix for the coloring of dashes following an
octopus merge. It makes a distinction between the case where all parents
introduce a new column, versus the case where the fi
The graph coloring logic for octopus merges currently has a bug. This
can be seen git.git with 74c7cfa875 (Merge of
http://members.cox.net/junkio/git-jc.git, 2005-05-05), whose second
child is 211232bae6 (Octopus merge of the following five patches.,
2005-05-05).
If one runs
git log
The graph coloring logic for octopus merges currently has a bug. This
can be seen git.git with 74c7cfa875 (Merge of
http://members.cox.net/junkio/git-jc.git, 2005-05-05), whose second
child is 211232bae6 (Octopus merge of the following five patches.,
2005-05-05).
If one runs
git log
On 6/26/2019 4:32 AM, Eugen Konkov wrote:
> Hello,
>
> For next diff the `}` line should not be detected as removed/added.
>
> As you can see there are differences only at new lines. (see attached
> pics)
>
> git version 2.21.0
>
>
> git diff -b -w --ignore-blank-lines
>
>
> git config:
>
Hello,
For next diff the `}` line should not be detected as removed/added.
As you can see there are differences only at new lines. (see attached
pics)
git version 2.21.0
git diff -b -w --ignore-blank-lines
git config:
[color "diff"]
old = red bold
new = green bold
[diff]
tool
I'll do the s/octu/octo/; again on the title while queuing.
Let's merge this to 'next'.
Thanks.
1 2
*
* In which case the number of parents will be one greater than the
* number of added columns.
*/
int added_cols = (graph->num_new_columns - graph->num_columns);
int parent_in_old_cols = graph->num_parents - added_cols;
From a9c90605c062b30273dad35adbf319905
Noam Postavsky writes:
> For octopus merges where the first parent edge immediately merges into
> the next column to the left:
>
> | *-.
> | |\ \
> |/ / /
>
> then the number of columns should be one less than the usual case:
>
> | *-.
> | |\ \
> | | | *
I had a bit hard time parsing the above,
For octopus merges where the first parent edge immediately merges into
the next column to the left:
| *-.
| |\ \
|/ / /
then the number of columns should be one less than the usual case:
| *-.
| |\ \
| | | *
Also refactor the code to iterate over columns rather than dashes,
building from an ini
Stefan Beller writes:
> On Sat, Aug 4, 2018 at 9:57 AM Junio C Hamano wrote:
>>
>> Stefan Beller writes:
>>
>> > This builds on top of sb/range-diff-colors, which builds on js/range-diff.
>>
>> As another round of js/range-diff is expected, according to
>>
>>
>
> Oh right. I forgot to mention
On Sat, Aug 4, 2018 at 9:57 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > This builds on top of sb/range-diff-colors, which builds on js/range-diff.
>
> As another round of js/range-diff is expected, according to
>
>
Oh right. I forgot to mention that in this cover letter, but Johann
Stefan Beller writes:
> This builds on top of sb/range-diff-colors, which builds on js/range-diff.
As another round of js/range-diff is expected, according to
I will refrain from queuing this right now. Possible conflict
resolution that won't be reusable when the base one is rerolled and
thi
w/context lines with prefixes as chosen by the user.
The first feature is to slightly adapt coloring of range-diff to have the
file markers
--- a/diff.c
+++ b/diff.c
be shown as context color. This is done by using custom prefixes for
old/new/context lines in the inner diffs and inden
Add a config option that allows selecting the default color scheme for
blame. The command line still takes precedence over the configuration.
It is to be seen, how color.ui will integrate with blame coloring.
Signed-off-by: Stefan Beller
---
Documentation/config.txt | 5 +
builtin/blame.c
On Fri, 6 Apr 2018 14:28:40 -0700
Stefan Beller wrote:
> Now that I redid it another way[1], I have the impression that this was the
> right approach, because it allows for a short
> if (o->color_moved)
> condition. If we treat white spaces separately, then we'd have to
> have implications such
On Mon, Apr 2, 2018 at 4:51 PM, Jonathan Tan wrote:
> On Mon, 2 Apr 2018 15:48:52 -0700
> Stefan Beller wrote:
>
>> At the time the move coloring was implemented we thought an enum of modes
>> is the best to configure this feature. However as we want to tack on new
>&g
On Tue, Apr 03 2018, Stefan Beller wrote:
> On Tue, Apr 3, 2018 at 12:39 PM, Ævar Arnfjörð Bjarmason
> wrote:
>>
>> On Mon, Apr 02 2018, Stefan Beller wrote:
>>
>>> At the time the move coloring was implemented we thought an enum of modes
>>> is the b
On Tue, Apr 3, 2018 at 12:39 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Mon, Apr 02 2018, Stefan Beller wrote:
>
>> At the time the move coloring was implemented we thought an enum of modes
>> is the best to configure this feature. However as we want to tack on new
>&g
On Mon, Apr 02 2018, Stefan Beller wrote:
> At the time the move coloring was implemented we thought an enum of modes
> is the best to configure this feature. However as we want to tack on new
> features, the enum would grow exponentially.
>
> Refactor the code such that featu
On Mon, Apr 2, 2018 at 4:51 PM, Jonathan Tan wrote:
> On Mon, 2 Apr 2018 15:48:52 -0700
> Stefan Beller wrote:
>
>> At the time the move coloring was implemented we thought an enum of modes
>> is the best to configure this feature. However as we want to tack on new
>&g
On Mon, 2 Apr 2018 15:48:52 -0700
Stefan Beller wrote:
> At the time the move coloring was implemented we thought an enum of modes
> is the best to configure this feature. However as we want to tack on new
> features, the enum would grow exponentially.
>
> Refactor the code suc
At the time the move coloring was implemented we thought an enum of modes
is the best to configure this feature. However as we want to tack on new
features, the enum would grow exponentially.
Refactor the code such that features are enabled via bits. Currently we can
* activate the move
On Thu, Feb 1, 2018 at 11:29 AM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, Jan 04 2018, Stefan Beller jotted:
>
>> Stefan Beller (4):
>> color.h: document and modernize header
>> builtin/blame: dim uninteresting metadata
>> builtin/blame: add option to color metadata fields separately
>>
On Thu, Jan 04 2018, Stefan Beller jotted:
> Stefan Beller (4):
> color.h: document and modernize header
> builtin/blame: dim uninteresting metadata
> builtin/blame: add option to color metadata fields separately
> builtin/blame: highlight recently changed lines
I like this feature in pr
v3:
Thanks Eric for feedback, I implemented all of the suggestions.
Specifically I dropped the abstractions in patch2 but keep around a similar
abstraction in patch 3 as that still looks like it benefits (the condition
is just growing large).
Thanks,
Stefan
v2:
This is picking up [1], but presen
This is picking up [1], but presenting it in another approach,
as I realized these are orthogonal features:
* dimming repeated lines/fields of information
* giving a quick visual information how old (as a proxy for 'well tested')
a line of code is.
Both features are configurable.
Changes from
This is picking up [1], but presenting it in another approach,
as I realized these are orthogonal features:
* dimming repeated lines/fields of information
* giving a quick visual information how old (as a proxy for 'well tested')
a line of code is.
Both features are configurable.
Any feedback
On Tue, Jun 27, 2017 at 8:14 PM, Junio C Hamano wrote:
>> diff --git a/diff.h b/diff.h
>> index 98abd75521..9298d211d7 100644
>> --- a/diff.h
>> +++ b/diff.h
>> @@ -192,6 +192,7 @@ struct diff_options {
>> COLOR_MOVED_NO = 0,
>> COLOR_MOVED_PLAIN = 1,
>> C
Stefan Beller writes:
> Introduce a new mode COLOR_MOVED_DEFAULT, which is the same as
> COLOR_MOVED_ZEBRA. But having two different symbols allows us to
> differentiate them in the code.
>
> Signed-off-by: Stefan Beller
> ---
> Documentation/diff-options.txt | 3 +++
> diff.c
Introduce a new mode COLOR_MOVED_DEFAULT, which is the same as
COLOR_MOVED_ZEBRA. But having two different symbols allows us to
differentiate them in the code.
Signed-off-by: Stefan Beller
---
Documentation/diff-options.txt | 3 +++
diff.c | 13 -
diff.h
On Tue, Jun 20 2017, Stefan Beller jotted:
> + Ævar, who was not part of the email where I copied all recipients
> from for this series.
I played around with this a bit, it would be great to have something
like this on top of --color-moved eventually. It's a lot easier to /^_
in a pager than loo
On Wed, Jun 21, 2017 at 2:55 PM, Junio C Hamano wrote:
> Brandon Williams writes:
>
>> On 06/19, Stefan Beller wrote:
>>> Ævar asked for it, this is how you would do it.
>>> (plus documentation, tests, CLI knobs, options)
>>>
>>> Signed-off-by: Stefan Beller
>>> ---
>>> diff.c | 15 +++-
Brandon Williams writes:
> On 06/19, Stefan Beller wrote:
>> Ævar asked for it, this is how you would do it.
>> (plus documentation, tests, CLI knobs, options)
>>
>> Signed-off-by: Stefan Beller
>> ---
>> diff.c | 15 +++
>> diff.h | 2 ++
>> 2 files changed, 13 insertions(+), 4 d
On 06/19, Stefan Beller wrote:
> Ævar asked for it, this is how you would do it.
> (plus documentation, tests, CLI knobs, options)
>
> Signed-off-by: Stefan Beller
> ---
> diff.c | 15 +++
> diff.h | 2 ++
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/diff.c
+ Ævar, who was not part of the email where I copied all recipients
from for this series.
On Mon, Jun 19, 2017 at 7:48 PM, Stefan Beller wrote:
> Ævar asked for it, this is how you would do it.
> (plus documentation, tests, CLI knobs, options)
>
> Signed-off-by: Stefan Beller
> ---
> diff.c | 1
Ævar asked for it, this is how you would do it.
(plus documentation, tests, CLI knobs, options)
Signed-off-by: Stefan Beller
---
diff.c | 15 +++
diff.h | 2 ++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index 7756f7610c..61caa057ff 100644
--- a/
On Wed, May 31, 2017 at 5:10 PM, Irving Rabin wrote:
>
> Thanks Jeff, my problem has been resolved by Samuel Lijin.
> My terminal settings didn't set bold which remained white. I fixed it
> and my problem was gone!
Specifically, Irving's terminal rendered bold text as white. No bug here :)
> Thi
Thanks Jeff, my problem has been resolved by Samuel Lijin.
My terminal settings didn't set bold which remained white. I fixed it
and my problem was gone!
This issue is closed. Is there any way to retire it?
Irving Rabin
Software Developer @Edmodo
408-242-1299
On Wed, May 31, 2017 at 2:04 PM, J
On Wed, May 31, 2017 at 11:33:31AM -0700, Irving Rabin wrote:
> Specifically, if the field is supposed to be white, it doesn't mean it
> should be literally 0xFF. It should be the color that I have
> configured as White color for my console emulator.
>
> I like light-screen terminals, and I c
On Wed, May 31, 2017 at 2:33 PM, Irving Rabin wrote:
>
> Folks, I am reporting an issue with coloring of the output of Git
> commands, like status, diff, etc.
>
> Specifically, if the field is supposed to be white, it doesn't mean it
> should be literally 0xFF. It sho
Folks, I am reporting an issue with coloring of the output of Git
commands, like status, diff, etc.
Specifically, if the field is supposed to be white, it doesn't mean it
should be literally 0xFF. It should be the color that I have
configured as White color for my console emulator.
I
Introduce a helper that calls ws_check_emit. We'll have it as a helper
as in a later patch we'll add buffering in there.
In a later patch we want to buffer up all output and to do that
we'll need to keep around information for outputting a line such
as the whitespace information. We choose to put
On Fri, Mar 21, 2014 at 12:41 AM, Junio C Hamano wrote:
> Why even include cache.h for S_IXUSR?
>
> In the context of the patch I see S_ISGID mentioned and other S_*
> st_mode things are already in use in this function before this step,
> and presumably you are using them without problems, no?
My
Duy Nguyen writes:
> On Thu, Mar 20, 2014 at 6:46 PM, Matthieu Moy
> wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> git-compat-util.h does not seem to carry S_IXUGO. Anyway as far as Git
>>> is concerned, we only care one executable bit. Hard code it.
>>
>> Why not use S_IXUSR instead of a hardc
On Thu, Mar 20, 2014 at 6:46 PM, Matthieu Moy
wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> git-compat-util.h does not seem to carry S_IXUGO. Anyway as far as Git
>> is concerned, we only care one executable bit. Hard code it.
>
> Why not use S_IXUSR instead of a hardcoded value? (already used in
>
Nguyễn Thái Ngọc Duy writes:
> git-compat-util.h does not seem to carry S_IXUGO. Anyway as far as Git
> is concerned, we only care one executable bit. Hard code it.
Why not use S_IXUSR instead of a hardcoded value? (already used in
path.c, so shouldn't be a problem wrt portability)
--
Matthieu
git-compat-util.h does not seem to carry S_IXUGO. Anyway as far as Git
is concerned, we only care one executable bit. Hard code it.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
ls_colors.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/ls_colors.c b/ls_colors.c
index d492ab3..
With kind regards,
Stefan
#!/bin/sh
#
# Copyright (c) 2014 Stefan-W. Hahn
#
test_description='Test coloring of diff with CRLF line ending.
'
. ./test-lib.sh
get_color ()
{
git config --get-color "$1"
}
test_expect_success setup '
git config color.diff
Am 14.02.2014 17:47, schrieb Stefan-W. Hahn:
>> It's the right solution. IOW, you should place something like this in
>> your .gitattributes:
>> *.html whitespace=cr-at-eol
>
> Sorry, but this is not possible, because I have files of both sorts (mainly
> C/C++) files in my repository and cannot c
6 AM.
| Please zip the attachment and send it again. If you have any questions,
| please contact IT. Thank you
|
| Message details:
| Server: ATLOWA1
| Sender: stefan.h...@s-hahn.de;
| Recipient: git@vger.kernel.org;
| Subject: Re: Bug: Problem with CRLF line ending in git-diff with coloring
| A
Mail von Stefan-W. Hahn, Sun, 09 Feb 2014 at 12:01:55 +0100:
Good afternoon,
I updated the test a little bit. Test 3 and 7 are going wrong.
Both tests have a CRLF line ending in the changed line.
I you redirect the output of the test to a file you see the main
problem:
,
| -[32m+[m[32mZe
Am 09.02.2014 12:01, schrieb Stefan-W. Hahn:
> Good morning,
>
> when diffing output where files have CRLF line ending, the coloring
> seems wrong, because in changed lines the CR (^M) is highlighted,
> even if the line ending has not changed.
...
> If WS_CR_AT_EOL is set in ec
Good morning,
when diffing output where files have CRLF line ending, the coloring
seems wrong, because in changed lines the CR (^M) is highlighted,
even if the line ending has not changed.
The diff engine itself is correct.
I added a test case to show this behaviour.
The problem seems to come
Ramkumar Ramachandra writes:
> So that we can extend it with ZSH-colors in a later patch.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> contrib/completion/git-prompt.sh | 79
> ++--
> 1 file changed, 43 insertions(+), 36 deletions(-)
>
> diff --git a/contr
So that we can extend it with ZSH-colors in a later patch.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-prompt.sh | 79 ++--
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion
So that we can extend it with ZSH-colors in a later patch.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-prompt.sh | 79 ++--
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion
This is not simply convenient over %C(auto,xxx). Some placeholders
(actually only one, %d) do multi coloring and we can't emit a multiple
colors with %C(auto,xxx).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/pretty-formats.txt | 3 ++-
pretty.c
Duy Nguyen writes:
>> This is to handle a corrupt input, e.g. "%C(auto)%Cbleu%H" where
>> (perhaps deprecated) "%Cblue" is misspelled, and parse_color()
>> returns 0 without consuming any byte.
>>
>> Does it make sense not to turn auto off in such a case?
>
> We don't have any mechanism to report
sumed 7 bytes, "C(auto)" */
> }
> c->auto_color_next = 0;
> return parse_color(sb, placeholder, c);
>
> which may be simpler. When we see %C, previous %C(auto) is
> cancelled.
If we do this, maybe we could show invalid %C with blinking. Quite
ca
Nguyễn Thái Ngọc Duy writes:
> case 'h': /* abbreviated commit hash */
> + strbuf_addstr(sb, diff_get_color(c->auto_color_next,
> DIFF_COMMIT));
> if (add_again(sb, &c->abbrev_commit_hash))
> return 1;
Doesn't this early retur
Nguyễn Thái Ngọc Duy writes:
> This is not simply convenient over %C(auto,xxx). Some placeholders
> (actually only one, %d) do multi coloring and we can't emit a multiple
> colors with %C(auto,xxx).
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentati
This is not simply convenient over %C(auto,xxx). Some placeholders
(actually only one, %d) do multi coloring and we can't emit a multiple
colors with %C(auto,xxx).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/pretty-formats.txt | 3 ++-
pretty.c
On Sat, Apr 6, 2013 at 4:13 AM, Junio C Hamano wrote:
> If %C(auto) applies to some % but not to some others,
> the user needs to learn which % will eat the "auto" (so
> it no longer applies to the next one) and which one will not even
> look at "auto" (so the next % is affected by the auto,
> i.e
Duy Nguyen writes:
> The above should have written "will turn on auto coloring on the
> following _textual_ placeholder". I didn't intend %C(auto) to be
> followed by %C(color) as it's already covered by %C(auto,red). But of
> course we could make it work too.
On Tue, Apr 2, 2013 at 5:26 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> This is not simply convenient over %C(auto,xxx). Some placeholders
>> (actually only one, %d) do multi coloring and we can't emit a multiple
>> colors with %C(auto,xxx).
>
Nguyễn Thái Ngọc Duy writes:
> This is not simply convenient over %C(auto,xxx). Some placeholders
> (actually only one, %d) do multi coloring and we can't emit a multiple
> colors with %C(auto,xxx).
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentati
This is not simply convenient over %C(auto,xxx). Some placeholders
(actually only one, %d) do multi coloring and we can't emit a multiple
colors with %C(auto,xxx).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/pretty-formats.txt | 3 ++-
pretty.c
On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy
wrote:
> This is not simply convenient over $C(auto,xxx). Some placeholders
s/\$/%/
> (actually only one, %d) do multi coloring and we can't emit a multiple
> colors with %C(auto,xxx).
>
> diff --git a/Documentation/pre
This is not simply convenient over $C(auto,xxx). Some placeholders
(actually only one, %d) do multi coloring and we can't emit a multiple
colors with %C(auto,xxx).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/pretty-formats.txt | 3 ++-
pretty.c
On Fri, Dec 21, 2012 at 8:15 AM, Jeff King wrote:
> On Thu, Dec 20, 2012 at 07:12:31PM -0800, Junio C Hamano wrote:
>> To conclude the bikeshedding discussion we had today, here is what I
>> queued by squashing stuff into relevant patches, so that people can
>> eyeball the result for the last time
On Thu, Dec 20, 2012 at 07:12:31PM -0800, Junio C Hamano wrote:
> To conclude the bikeshedding discussion we had today, here is what I
> queued by squashing stuff into relevant patches, so that people can
> eyeball the result for the last time.
Thanks, this looks OK to me.
And thank you, Adam, f
To conclude the bikeshedding discussion we had today, here is what I
queued by squashing stuff into relevant patches, so that people can
eyeball the result for the last time.
Adam Spiers (7):
tests: test number comes first in 'not ok $count - $message'
tests: paint known breakages in yellow
On Thu, Dec 20, 2012 at 7:21 PM, Junio C Hamano wrote:
> Jeff King writes:
>>> Good point, I forgot to check what it looked like with -v. Since this
>>> series is already on v6, is there a more lightweight way of addressing
>>> this tiny tweak than sending v7?
>>
>> It is ultimately up to Junio,
On Thu, Dec 20, 2012 at 11:21:09AM -0800, Junio C Hamano wrote:
> The "expected_failure" cases painted in "warn" are all long-known
> failures; I do not think reminding about them in "bold" over and
> over will help encouraging the developers take a look at them.
>
> The "skipped" cases fall into
Jeff King writes:
>> Good point, I forgot to check what it looked like with -v. Since this
>> series is already on v6, is there a more lightweight way of addressing
>> this tiny tweak than sending v7?
>
> It is ultimately up to Junio, but I suspect he would be OK if you just
> reposted patch 4/7
On Thu, Dec 20, 2012 at 4:11 PM, Jeff King wrote:
> On Thu, Dec 20, 2012 at 03:44:53PM +, Adam Spiers wrote:
>> > diff --git a/t/test-lib.sh b/t/test-lib.sh
>> > index 256f1c6..31f59af 100644
>> > --- a/t/test-lib.sh
>> > +++ b/t/test-lib.sh
>> > @@ -227,7 +227,7 @@ then
>> > p
On Thu, Dec 20, 2012 at 03:44:53PM +, Adam Spiers wrote:
> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 256f1c6..31f59af 100644
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -227,7 +227,7 @@ then
> > pass)
> > tput setaf 2;;
On Thu, Dec 20, 2012 at 3:34 PM, Jeff King wrote:
> On Sun, Dec 16, 2012 at 07:01:56PM +, Adam Spiers wrote:
>> On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano wrote:
>> > Adam Spiers writes:
>> >> This series of commits attempts to make test output
On Sun, Dec 16, 2012 at 07:01:56PM +, Adam Spiers wrote:
> On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano wrote:
> > Adam Spiers writes:
> >
> >> This series of commits attempts to make test output coloring
> >> more intuitive,...
> >
> > Tha
Adam Spiers writes:
> On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano wrote:
>> Adam Spiers writes:
>>
>>> This series of commits attempts to make test output coloring
>>> more intuitive,...
>>
>> Thanks; I understand that this is to repl
On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano wrote:
> Adam Spiers writes:
>
>> This series of commits attempts to make test output coloring
>> more intuitive,...
>
> Thanks; I understand that this is to replace the previous one
> b465316 (tests: paint unexpected
Adam Spiers writes:
> This series of commits attempts to make test output coloring
> more intuitive,...
Thanks; I understand that this is to replace the previous one
b465316 (tests: paint unexpectedly fixed known breakages in bold
red, 2012-09-19)---am I correct?
> - red is only
This series of commits attempts to make test output coloring
more intuitive, so that:
- red is only used for things which have gone unexpectedly wrong:
test failures, unexpected test passes, and failures with the
framework,
- yellow is only used for known breakages,
- green is
tion
+- '%C(auto[,])': turn on coloring on the next placeholder (or the next N
placeholders) if supported
- '%m': left, right or boundary mark
- '%n': newline
- '%%': a raw '%'
diff --git a/pretty.c b/pretty.c
index 93c96c2..45fe878 10064
tion
+- '%C(auto[,])': turn on coloring on the next placeholder (or the next N
placeholders) if supported
- '%m': left, right or boundary mark
- '%n': newline
- '%%': a raw '%'
diff --git a/pretty.c b/pretty.c
index 93c96c2..45fe878 10064
On Wed, Sep 19, 2012 at 09:12:01PM +0100, Adam Spiers wrote:
> > > Sounds reasonable, and I think the new output looks nice. I notice that
> > > skipped tests are still in green. I wonder if they should be in yellow,
> > > too.
> > >
> > What about blue instead? This would keep the colouring sch
On Wed, Sep 19, 2012 at 10:02:52PM +0200, Stefano Lattarini wrote:
> On 09/17/2012 10:11 PM, Jeff King wrote:
> > On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote:
> >
> >> The end result of these changes is that:
> >>
> >> - red is _only_ used for things which have gone unexpectedly
On 09/17/2012 10:11 PM, Jeff King wrote:
> On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote:
>
>> The end result of these changes is that:
>>
>> - red is _only_ used for things which have gone unexpectedly wrong:
>> test failures, unexpected test passes, and failures with the
>>
On Wed, Sep 19, 2012 at 06:15:09PM +0100, Adam Spiers wrote:
> This series of commits attempts to make test output coloring
> more intuitive, so that:
>
> - red is _only_ used for things which have gone unexpectedly wrong:
> test failures, unexpected test passes, and fa
This series of commits attempts to make test output coloring
more intuitive, so that:
- red is _only_ used for things which have gone unexpectedly wrong:
test failures, unexpected test passes, and failures with the
framework,
- yellow is _only_ used for known breakages and skipped
On Tue, Sep 18, 2012 at 10:59 PM, Jeff King wrote:
> TODO is a special token[1] respected by TAP harnesses like "prove". I'm
> not sure what practical impact it has, but it should probably remain.
>
> -Peff
>
> [1] http://testanything.org/wiki/index.php/TAP_specification#TODO_tests
Thanks, I didn
On Tue, Sep 18, 2012 at 10:36:17PM +0100, Adam Spiers wrote:
> > > + say_color error "ok $test_count - $@ # TODO known breakage vanished"
> > > }
> >
> > Also I wonder if this is still a "TODO".
>
> Hah, I should trust my first instincts more; my first version of the
> patch dropped the "TODO",
On Mon, Sep 17, 2012 at 01:50:39PM -0700, Junio C Hamano wrote:
> Adam Spiers writes:
>
> > 1. Change the color of individual known breakages from bold green to
> >bold yellow. This seems more appropriate when considering the
> >universal traffic lights colo
On Mon, Sep 17, 2012 at 04:11:19PM -0400, Jeff King wrote:
> On Mon, Sep 17, 2012 at 12:50:37PM +0100, Adam Spiers wrote:
>
> > The end result of these changes is that:
> >
> > - red is _only_ used for things which have gone unexpectedly wrong:
> > test failures, unexpected test passes, and
Adam Spiers writes:
> 1. Change the color of individual known breakages from bold green to
>bold yellow. This seems more appropriate when considering the
>universal traffic lights coloring scheme, where green conveys the
>impression that everything's OK, and amber
1 - 100 of 102 matches
Mail list logo
