* [PATCH v7 0/7] coloring test output after traffic signal
From: Junio C Hamano @ 2012-12-21 3:12 UTC (permalink / raw)
To: git; +Cc: Adam Spiers, Jeff King
In-Reply-To: <CAOkDyE9tDYRYzojzNnjWsT7UygxMAurHqLSDGA66_LMPD2Wmnw@mail.gmail.com>
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
tests: paint skipped tests in blue
tests: change info messages from yellow/brown to cyan
tests: refactor mechanics of testing in a sub test-lib
tests: test the test framework more thoroughly
tests: paint unexpectedly fixed known breakages in bold red
t/t0000-basic.sh | 214 ++++++++++++++++++++++++++++++++++++++++++-------------
t/test-lib.sh | 29 +++++---
2 files changed, 184 insertions(+), 59 deletions(-)
--
1.8.1.rc2.225.g8d36ab4
^ permalink raw reply
* Re: [PATCH] Documentation/git-clean: Document --force --force
From: Junio C Hamano @ 2012-12-21 3:01 UTC (permalink / raw)
To: Soren Brinkmann; +Cc: git
In-Reply-To: <335802a0-38b5-4cbc-9e52-92c92083119e@VA3EHSMHS005.ehs.local>
Soren Brinkmann <soren.brinkmann@xilinx.com> writes:
> Ping?
I *think* it is a mistake for the command to remove a separate
project repository within, with any number of "-f", so I'd rather
see a patch to fix it, instead of casting such a misbehaviour as a
feature in stone by documenting it.
I dunno.
> On Thu, Dec 13, 2012 at 05:46:55PM -0800, Soren Brinkmann wrote:
>> This patch documents the behavior of 'git clean' when
>> encountering nested git repositories.
>> Such repositories are only deleted if '-f' is passed twice
>> to 'git clean'.
>>
>> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
>> ---
>> Documentation/git-clean.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
>> index 9f42c0d..0b31454 100644
>> --- a/Documentation/git-clean.txt
>> +++ b/Documentation/git-clean.txt
>> @@ -23,6 +23,9 @@ example, be useful to remove all build products.
>> If any optional `<path>...` arguments are given, only those paths
>> are affected.
>>
>> +Nested git repositories are not removed unless the '-f' option is
>> +passed to 'git clean' twice.
>> +
>> OPTIONS
>> -------
>> -d::
>> @@ -35,6 +38,8 @@ OPTIONS
>> --force::
>> If the git configuration variable clean.requireForce is not set
>> to false, 'git clean' will refuse to run unless given -f or -n.
>> + Pass this option twice to 'git clean' in order to also remove
>> + nested git repositories.
>>
>> -n::
>> --dry-run::
>> --
>> 1.8.0.2
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* Re: [PATCH] Documentation/git-update-index: caution about tree objects
From: Junio C Hamano @ 2012-12-21 2:56 UTC (permalink / raw)
To: Greg Troxel; +Cc: git
In-Reply-To: <1356053738-14926-1-git-send-email-gdt@ir.bbn.com>
Greg Troxel <gdt@ir.bbn.com> writes:
> While one can add tree objects to the index, this is not currently
> useful. Therefore, use "git ls-tree -r" as the example to be fed to
> --index-info. Add a section explaining about expected index contents.
> (Thanks to Junio for explaining this to me in August of 2011.)
>
> Signed-off-by: Greg Troxel <gdt@ir.bbn.com>
> ---
> Documentation/git-update-index.txt | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
> index 9d0b151..6ce65fa 100644
> --- a/Documentation/git-update-index.txt
> +++ b/Documentation/git-update-index.txt
> @@ -29,6 +29,11 @@ Modifies the index or directory cache. Each file mentioned is updated
> into the index and any 'unmerged' or 'needs updating' state is
> cleared.
>
> +Note that update-index does not check that the modifications preserve
> +the expected invariants. In particular, an index normally holds
> +regular blobs, executable blobs, symlink blobs, and gitlinks.
> +Therefore, adding a tree object is not likely useful.
> +
I find this unnecessarily alarmist as a description meant for
general audiences. For the normal mode of operations of the command
(e.g. "git update-index --add --remove hello.c"), whatever you mean
by "expected invariants" are fully preserved.
I think you meant this for --cacheinfo and --index-info options,
which are primarily meant for people who know what they are doing
(that includes the use of this command in scripted Porceains) or Git
developers who want to work on enhancing the index (and to them,
being able to record anything is more convenient).
> @@ -210,7 +215,7 @@ back on 3-way merge.
>
> . mode SP type SP sha1 TAB path
> +
> -The second format is to stuff 'git ls-tree' output
> +The second format is to stuff 'git ls-tree -r' output
> into the index file.
This hunk is good.
Thanks.
^ permalink raw reply
* Re: Noob Question
From: Andrew Ardill @ 2012-12-21 1:43 UTC (permalink / raw)
To: awingnut; +Cc: git@vger.kernel.org
In-Reply-To: <50D3B669.1030204@hotmail.com>
Hi!
On 21 December 2012 12:07, awingnut <wtriker.ffe@gmail.com> wrote:
> My main questions center around the git repository and accessing it.
The main thing you need to know is that you can work on your code base
in the *exact* same way while using git. You don't *have* to change
anything about how you work, as git's primary purpose is to store
snapshots of your work so that you have a history of what has changed.
That being said, you can (and maybe should) change how you work to
take into account the power of git. Most of what you do will stay the
same, however.
> 1) Should I install git on Linux or Windows or does it matter?
Install git wherever you need to access the code. From the sounds of
it you will want git on both machines, as you are working on windows
and but keeping the code on the linux shared drive. When working on
the windows machine you will use a windows copy of git to manipulate
the workspace, though I'm not sure if there are any gotchas with the
interaction with a linux shared drive.
If you want to manipulate the repository from the linux machine you
will need git on it as well.
Unless you're using a git server, manipulating the repository is a
local action and so is performed by the client. That is, when working
on windows use the windows client, if you also work on the linux
machine then you will need a client there as well.
> 2) How will my build scripts access the source? Will it be the same as
> now (my scripts 'cd' to the Eclipse project directory and run there) or
> do I need to add a wrapper to my script to check out the entire source
> for the builds?
It's the same as now. Git uses the concept of a 'work tree' to talk
about the actual files you are working on now. The work tree
corresponds exactly to your current project files. When you create a
git repository you gain the ability to store snapshots of this working
tree into the 'object store', as well as metadata about the snapshots,
so that you can restore that snapshot later.
Your actual files keep their current layout and format, until you change them.
> 3) How do I move my current Eclipse project into git after I create the
> empty repository? I can only find info on how to import git into Eclipse
> not the other way around.
You have two options. Create the git repository in the same location
as your Eclipse project. Navigate to the project folder using git bash
and do a 'git init' inside it; voila! you now have a git repository.
You can choose to create a 'remote' repository somewhere to store a
backup of your code as well, but this _still_ requires you to init a
local repository to backup.
The other option is to create a blank repository somewhere (anywhere)
and then tell that repository to use your Eclipse project as its
working tree. The benefit to doing this is being able to keep your
snapshots and metadata in a different location to your working
directory (say keep the snapshots on a local windows drive while your
working directory is on the linux share). Unless you shouldn't or
aren't able to create the repository within the Eclipse project, I
would recommend against this.
> 4) Do I need to checkout the entire project from Eclipse to modify and
> test it or only the classes I want to change? Does the plugin get the
> others as needed when I run the app within Eclipse for testing?
Not sure exactly what you are asking here, but in general people will
'clone' an entire repository including all its history. If you want to
update only certain files that is fine, but the commit object stores
the state of the entire tree of files. Note that a commit object does
_not_ store the difference between two snapshots, but stores the
entire state of the files. You can grab a file from a given snapshot
and test that along side files from a second snapshot, but if you
wanted to commit the resulting tree to the repository it would store a
third snapshot containing the exact state of all files.
Hopefully that clears it up for you?
Regards,
Andrew Ardill
^ permalink raw reply
* [PATCH] Documentation/git-update-index: caution about tree objects
From: Greg Troxel @ 2012-12-21 1:35 UTC (permalink / raw)
To: git; +Cc: Greg Troxel
While one can add tree objects to the index, this is not currently
useful. Therefore, use "git ls-tree -r" as the example to be fed to
--index-info. Add a section explaining about expected index contents.
(Thanks to Junio for explaining this to me in August of 2011.)
Signed-off-by: Greg Troxel <gdt@ir.bbn.com>
---
Documentation/git-update-index.txt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 9d0b151..6ce65fa 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -29,6 +29,11 @@ Modifies the index or directory cache. Each file mentioned is updated
into the index and any 'unmerged' or 'needs updating' state is
cleared.
+Note that update-index does not check that the modifications preserve
+the expected invariants. In particular, an index normally holds
+regular blobs, executable blobs, symlink blobs, and gitlinks.
+Therefore, adding a tree object is not likely useful.
+
See also linkgit:git-add[1] for a more user-friendly way to do some of
the most common operations on the index.
@@ -210,7 +215,7 @@ back on 3-way merge.
. mode SP type SP sha1 TAB path
+
-The second format is to stuff 'git ls-tree' output
+The second format is to stuff 'git ls-tree -r' output
into the index file.
. mode SP sha1 SP stage TAB path
--
1.8.0.1
^ permalink raw reply related
* Noob Question
From: awingnut @ 2012-12-21 1:07 UTC (permalink / raw)
To: git
I have not used git yet but am planning to. I am trying to get my head
around how it will work and the documentation I found so far is of
modest help. I currently have a Java application developed using Eclipse
on Windows. However, the project is located on a Linux shared drive
which is my Eclipse workspace. I do my builds using ANT on the Linux
host. My main questions center around the git repository and accessing it.
1) Should I install git on Linux or Windows or does it matter?
2) How will my build scripts access the source? Will it be the same as
now (my scripts 'cd' to the Eclipse project directory and run there) or
do I need to add a wrapper to my script to check out the entire source
for the builds?
3) How do I move my current Eclipse project into git after I create the
empty repository? I can only find info on how to import git into Eclipse
not the other way around.
4) Do I need to checkout the entire project from Eclipse to modify and
test it or only the classes I want to change? Does the plugin get the
others as needed when I run the app within Eclipse for testing?
Thanks for any help understanding how I need to configure all this.
^ permalink raw reply
* Re: [PATCH] Documentation/git-clean: Document --force --force
From: Soren Brinkmann @ 2012-12-20 23:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <b48ad5f0-25f7-45c3-b2dc-c0c01645a247@CO9EHSMHS031.ehs.local>
Ping?
On Thu, Dec 13, 2012 at 05:46:55PM -0800, Soren Brinkmann wrote:
> This patch documents the behavior of 'git clean' when
> encountering nested git repositories.
> Such repositories are only deleted if '-f' is passed twice
> to 'git clean'.
>
> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
> ---
> Documentation/git-clean.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
> index 9f42c0d..0b31454 100644
> --- a/Documentation/git-clean.txt
> +++ b/Documentation/git-clean.txt
> @@ -23,6 +23,9 @@ example, be useful to remove all build products.
> If any optional `<path>...` arguments are given, only those paths
> are affected.
>
> +Nested git repositories are not removed unless the '-f' option is
> +passed to 'git clean' twice.
> +
> OPTIONS
> -------
> -d::
> @@ -35,6 +38,8 @@ OPTIONS
> --force::
> If the git configuration variable clean.requireForce is not set
> to false, 'git clean' will refuse to run unless given -f or -n.
> + Pass this option twice to 'git clean' in order to also remove
> + nested git repositories.
>
> -n::
> --dry-run::
> --
> 1.8.0.2
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v6 0/7] make test output coloring more intuitive
From: Adam Spiers @ 2012-12-20 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git list
In-Reply-To: <7vy5gs4jiy.fsf@alter.siamese.dyndns.org>
On Thu, Dec 20, 2012 at 7:21 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> 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 with the above squashed. Or even just said "I like
>> this, please squash it into patch 4 (change info messages from
>> yellow/brown to bold cyan).
>
> Surely; as long as the series is not in 'next', the change to be
> squashed is not too big and it is not too much work (and in this
> case it certainly is not).
OK.
> I actually wonder if "skipped test in bold blue" and "known breakage
> in bold yellow" should also lose the boldness. Errors and warnings
> in bold are good, but I would say the degree of need for attention
> are more like this:
>
> error (failed tests - you should look into it)
> skip (skipped - perhaps you need more packages?)
> warn (expected failure - you may want to look into fixing it someday)
> info
> pass
>
> 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.
As Peff already noted, on many (most?) X terminals "bold" colours are
just brighter colours, rather than a heavier typeface. How bold they
look is therefore dependent on the colour scheme used by that
terminal.
> The "skipped" cases fall into two categories. Either you already
> know you choose to not to care (e.g. I do not expect to use git-p4
> and decided not to install p4 anywhere, so I may have t98?? on
> GIT_SKIP_TESTS environment) or you haven't reached that point on a
> new system and haven't realized that you didn't install a package
> needed to run tests you care about (e.g. cvsserver tests would not
> run without Perl interface to SQLite). For the former, the bold
> output is merely distracting; for the latter, bold _might_ help in
> this case.
Very good point.
> At least, I think
>
> GIT_SKIP_TESTS=t98?? sh t9800-git-p4-basic.sh -v
>
> should paint "skipping test t9800 altogether" (emitted with "-v) and
> the last line "1..0 # SKIP skip all tests in t9800" both in the same
> "info" color.
>
> How about going further to reduce "bold" a bit more, like this?
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index aaf013e..2bbb81d 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -182,13 +182,13 @@ then
> error)
> tput bold; tput setaf 1;; # bold red
> skip)
> - tput bold; tput setaf 4;; # bold blue
> + tput setaf 4;; # bold blue
The comment still says "bold".
> warn)
> - tput bold; tput setaf 3;; # bold brown/yellow
> + tput setaf 3;; # bold brown/yellow
Ditto here ...
> pass)
> tput setaf 2;; # green
> info)
> - tput bold; tput setaf 6;; # bold cyan
> + tput setaf 6;; # bold cyan
... and here.
> *)
> test -n "$quiet" && return;;
> esac
> @@ -589,7 +589,7 @@ for skp in $GIT_SKIP_TESTS
> do
> case "$this_test" in
> $skp)
> - say_color skip >&3 "skipping test $this_test altogether"
> + say_color info >&3 "skipping test $this_test altogether"
> skip_all="skip all tests in $this_test"
> test_done
> esac
Yes, I like this last hunk especially.
I have no objection in principle to a reduction in boldness.
However, I am beginning to get disheartened that at this rate, this
series will never land. I already submitted v4 of the series which
already had non-bold blue. I then received feedback indicating that
bold blue would be more suitable, so despite alarm bells beginning to
ring in my head, I submitted v5 with bold blue, declaring that that
would be my last version:
http://article.gmane.org/gmane.comp.version-control.git/206042
A further concern about "info" messages not being blue prompted me
to attempt to canvass more opinions:
http://article.gmane.org/gmane.comp.version-control.git/209321
I received none, so submitted v6 based on my best judgement. Now we
are talking about a potential v7 going *back* to non-bold blue. I can
submit v7 if you think it's worth it, but would that really be the end
of the discussion? It's clear from the above that colour scheme
design by committee is about as good an idea as asking a bunch of kids
to reach consensus on their favourite colour ;-)
So if possible I'd be very happy for Junio to simply make an executive
decision (I don't care which way, as long as it fits the traffic
lights scheme and uses distinct hues of blue/cyan for the different
categories of skip/info messages), tweak the latest v6 series
accordingly, and then push so that we can all go back to more pressing
things ;-)
Hopefully that is a reasonable way forward?
Thanks,
Adam
^ permalink raw reply
* Re: [PATCH] Highlight the link target line in Gitweb using CSS
From: Matthew Blissett @ 2012-12-20 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narębski
In-Reply-To: <7vbodo4f6q.fsf@alter.siamese.dyndns.org>
On 20 December 2012 20:54, Junio C Hamano <gitster@pobox.com> wrote:
> [jc: adding area expert to Cc]
Thanks.
> Matthew Blissett <matt@blissett.me.uk> writes:
>
> > This is useful when a Gitweb link with a target (like #l100) refers to
> > a line in the last screenful of text. Highlight the background in
> > yellow, and display a ⚓ character on the left. Show the same
> > highlight when hovering the mouse over a line number.
> >
> > Signed-off-by: Matthew Blissett <matt@blissett.me.uk>
> > ---
> > The background-colour change is the 'main' (tiny) change.
>
> In the "blob" view, I think it does make it more discoverable that
> these line numbers are links, so I personally think a.linenr:hover
> part is an improvement. I am not sure about other three changes
> adding any value, though.
>
> > Consider the ::before part a suggestion. I think it helps show the
> > target line, but it does overlap the first character of any line >999.
>
> Actually, when viewing the blame view, this is even worse, as it
> seems to always overlap. The background color ought to be enough
> cue without being overly distracting, I would have to say.
I didn't know about blame-view, sorry. The line-number links in that
view aren't self-referential, so the ⚓ symbol is misleading. I'm not
sure if that's a mistake, or if the links are supposed to point to the
commit that introduced the change. In any case, often they point to
the parent commit instead.
Just this:
/* Pink highlight when hovering line numbers or linking to them */
.pre a.linenr:hover,
.pre a.linenr:target {
color: #444444;
background-color: #f8f;
}
is probably best. A pink background, which shows up better than
yellow, and only in blob view. The :target background also helps mark
the chosen line after scrolling.
If blame view is supposed to have the same behaviour (self-referential
links) then these two CSS selectors are appropriate:
.blame tr:target .linenr a, .blame tr .linenr a:hover
--
Thanks,
Matt
^ permalink raw reply
* Re: RFC: "git config -l" should not expose sensitive information
From: Andrew Ardill @ 2012-12-20 22:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, Jeff King, Toralf Förster,
git@vger.kernel.org
In-Reply-To: <7vbodo5zjj.fsf@alter.siamese.dyndns.org>
On 21 December 2012 02:49, Aaron Schrab <aaron@schrab.com> wrote:
> Tools outside of the core git tree may add support for new config keys which
> are meant to contain sensitive information, and there would be no way for
> `git config` to know about those.
I understand that we've come down mostly on the 'users must check
before sending' side of things, but this point isn't necessarily true.
It wouldn't be too hard to create a config setting with a list of
'sensitive' keys filled with sensible defaults. It would be the job of
the 3rd party to add the relevant keys to this config file. This
wouldn't help with old 3rd party tools but would provide a way to
'hide' things automatically. A user could of course configure this
themselves (though one would think most who knew how wouldn't need
to).
On 21 December 2012 02:52, Jeff King <peff@peff.net> wrote:
>> I think that attempting to do this would only result in a false sense
>> of security.
>
> Yeah. Thanks for a dose of sanity. I was really trying not to say "the
> given advice is bad, and we cannot help those people". But I think you
> are right; the only sensible path is for the user to inspect the output
> before posting it.
One thing that a new option could provide (or maybe even the existing
option if it detects an interactive session) is to prompt the user to
review the content before outputting it. This is a nice way of helping
users who don't know that there might be sensitive information in the
output. Are there any use cases where prompting the user would be
annoying when using this command?
Regards,
Andrew Ardill
^ permalink raw reply
* Change in cvsps maintainership, abd a --fast-export option
From: Eric S. Raymond @ 2012-12-20 21:56 UTC (permalink / raw)
To: git
Earlier today David Mansfield handed off to me the cvsps project. This
is the code used as an engine for reading CVS repositories by
git-cvsimport.
His reason (aside from general overwork and no longer having a strong
interest on the code) is that I have added a --fast-export option to
cvsps-3.0 that emits a git fast-import stream representing the CVS
history.
I did this so that reposurgeon could use cvsps as a front end. But I
expect it will be of some interest to whoever is maintaining
git-cvsimport. That code can now become much, *much* smaller and
simpler.
The new --fast-export mode solves at least one bug mentioned on the
git-cvsimport man page; multiple tags pointing at the same CVS changeset
will be passed through correctly.
Possibly it fixes some other problems described there as well.
I don't understand all the bug warnings on that page and would like to
discuss them with the author, whoever that is. Possibly cvsps can be
further enhanced to address these problems; I'm willing to work on that.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
-- Lazarus Long
^ permalink raw reply
* Re: Python version auditing followup
From: Junio C Hamano @ 2012-12-20 21:39 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <kb001v$vps$1@ger.gmane.org>
"Joachim Schmitz" <jojo@schmitz-digital.de> writes:
> Junio C Hamano wrote:
>> I personally would think 2.6 is recent enough. Which platforms that
>> are long-term-maintained by their vendors still pin their Python at
>> 2.4.X? 2.4.6 was in 2008 that was source only, 2.4.4 was in late
>> 2006 that was the last 2.4 with binary release.
>>
>> Objections? Comments?
>
> We have a working 2.4.2 for HP-NonStop and some major problems getting
> 2.7.3 to work.
I do not think a platform that stops at 2.4.2 instead of going to
higher 2.4.X series deserves to be called "long term maintained by
their vendors". It sounds more like "attempted to supply 2.4.X and
abandoned the users once onee port was done" to me.
^ permalink raw reply
* Re: Python version auditing followup
From: Joachim Schmitz @ 2012-12-20 21:30 UTC (permalink / raw)
To: git
In-Reply-To: <7vobho60fs.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> esr@thyrsus.com (Eric S. Raymond) writes:
>
>> That was the first of three patches I have promised. In order to do
>> the next one, which will be a development guidelines recommend
>> compatibility back to some specific version X, I need a policy
>> decision. How do we set X?
>>
>> I don't think X can be < 2.4, nor does it need to be - 2.4 came out
>> in 2004 and eight years is plenty of deployment time.
>>
>> The later we set it, the more convenient for developers. But of
>> course by setting it late we trade away some portability to
>> older systems.
>>
>> In previous discussion of this issue I recommended X = 2.6.
>> That is still my recommendation. Thoughts, comments, objections?
>
> I personally would think 2.6 is recent enough. Which platforms that
> are long-term-maintained by their vendors still pin their Python at
> 2.4.X? 2.4.6 was in 2008 that was source only, 2.4.4 was in late
> 2006 that was the last 2.4 with binary release.
>
> Objections? Comments?
We have a working 2.4.2 for HP-NonStop and some major problems getting 2.7.3
to work.
Bye, Jojo
^ permalink raw reply
* Re: $PATH pollution and t9902-completion.sh
From: Jeff King @ 2012-12-20 21:04 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Junio C Hamano, Adam Spiers, git mailing list
In-Reply-To: <50D37AB2.1040508@web.de>
On Thu, Dec 20, 2012 at 09:53:06PM +0100, Torsten Bögershausen wrote:
> (Good to learn about the comm command, thanks )
> What do we think about this:
>
>
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 3cd53f8..82eeba7 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -62,12 +62,16 @@ test_completion ()
> {
> if test $# -gt 1
> then
> - printf '%s\n' "$2" >expected
> + printf '%s\n' "$2" | sort >expected.sorted
> else
> - sed -e 's/Z$//' >expected
> + sed -e 's/Z$//' | sort >expected.sorted
> fi &&
> run_completion "$1" &&
> - test_cmp expected out
> + sort <out >actual.sorted &&
> + >empty &&
> + comm -23 expected.sorted actual.sorted >actual &&
> + test_cmp empty actual &&
> + rm empty actual
I like test_* helpers that tell you what happened on error, but this
output will be kind of a weird diff (it is a diff showing things you
expected to have but did not get as additions, and no mention of things
you expected and got).
The output is human readable, so I think it is perfectly OK to print a
message about what is going on (we do this in test_expect_code, for
example). Something like:
test_fully_contains() {
sort "$1" >expect.sorted &&
sort "$2" >actual.sorted &&
comm -23 expect.sorted actual.sorted >missing
test -f missing -a ! -s missing &&
rm -f expect.sorted actual.sorted missing &&
return 0
{
echo "test_fully_contains: some lines were missing"
echo "expected:"
sed 's/^/ /' <"$1"
echo "actual:"
sed 's/^/ /' <"$2"
echo "missing:"
sed 's/^/ /' <missing
} >&2
return 1
}
Though come to think of it, just showing the diff between expect.sorted
and actual.sorted would probably be enough. It would show the missing
elements as deletions, the found elements as common lines, and the
"extra" elements as additions (which are not an error, but when you are
debugging, might be useful to know about).
-Peff
^ permalink raw reply
* [PATCH v2] oneway_merge(): only lstat() when told to update worktree
From: Martin von Zweigbergk @ 2012-12-20 21:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin von Zweigbergk
In-Reply-To: <7vk3sc4hle.fsf@alter.siamese.dyndns.org>
Although the subject line of 613f027 (read-tree -u one-way merge fix
to check out locally modified paths., 2006-05-15) mentions "read-tree
-u", it did not seem to check whether -u was in effect. Not checking
whether -u is in effect makes e.g. "read-tree --reset" lstat() the
worktree, even though the worktree stat should not matter for that
operation.
This speeds up e.g. "git reset" a little on the linux-2.6 repo (best
of five, warm cache):
Before After
real 0m0.288s 0m0.233s
user 0m0.190s 0m0.150s
sys 0m0.090s 0m0.080s
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
---
unpack-trees.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 6d96366..61acc5e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1834,7 +1834,7 @@ int oneway_merge(struct cache_entry **src, struct unpack_trees_options *o)
if (old && same(old, a)) {
int update = 0;
- if (o->reset && !ce_uptodate(old) && !ce_skip_worktree(old)) {
+ if (o->reset && o->update && !ce_uptodate(old) && !ce_skip_worktree(old)) {
struct stat st;
if (lstat(old->name, &st) ||
ie_match_stat(o->src_index, old, &st, CE_MATCH_IGNORE_VALID|CE_MATCH_IGNORE_SKIP_WORKTREE))
--
1.8.0.1.240.ge8a1f5a
^ permalink raw reply related
* Re: $PATH pollution and t9902-completion.sh
From: Junio C Hamano @ 2012-12-20 21:02 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Jeff King, Adam Spiers, git mailing list
In-Reply-To: <50D37AB2.1040508@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> On 20.12.12 21:01, Jeff King wrote:
>> +test_fully_contains () {
>>> + sort "$1" >expect.sorted &&
>>> + sort "$2" >actual.sorted &&
>>> + test $(comm -23 expect.sorted actual.sorted | wc -l) = 0
>>> +}
>
> (Good to learn about the comm command, thanks )
> What do we think about this:
Three points to consider.
* Do _all_ tests that use test_completion not care about the actual
order of choices that come out of the completion machinery?
* Do _all_ tests that use test_completion not care about having
extra choice, or is the command name completion the only odd
case?
* Is this still as easy to extend as the original to conditionally
verify that all extra output share the same prefix?
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 3cd53f8..82eeba7 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -62,12 +62,16 @@ test_completion ()
> {
> if test $# -gt 1
> then
> - printf '%s\n' "$2" >expected
> + printf '%s\n' "$2" | sort >expected.sorted
> else
> - sed -e 's/Z$//' >expected
> + sed -e 's/Z$//' | sort >expected.sorted
> fi &&
> run_completion "$1" &&
> - test_cmp expected out
> + sort <out >actual.sorted &&
> + >empty &&
> + comm -23 expected.sorted actual.sorted >actual &&
> + test_cmp empty actual &&
> + rm empty actual
> }
>
> # Test __gitcomp.
^ permalink raw reply
* Re: [PATCH] Highlight the link target line in Gitweb using CSS
From: Junio C Hamano @ 2012-12-20 20:54 UTC (permalink / raw)
To: Matthew Blissett; +Cc: git, Jakub Narębski
In-Reply-To: <1356027399-5356-1-git-send-email-matt@blissett.me.uk>
[jc: adding area expert to Cc]
Matthew Blissett <matt@blissett.me.uk> writes:
> This is useful when a Gitweb link with a target (like #l100) refers to
> a line in the last screenful of text. Highlight the background in
> yellow, and display a ⚓ character on the left. Show the same
> highlight when hovering the mouse over a line number.
>
> Signed-off-by: Matthew Blissett <matt@blissett.me.uk>
> ---
> The background-colour change is the 'main' (tiny) change.
In the "blob" view, I think it does make it more discoverable that
these line numbers are links, so I personally think a.linenr:hover
part is an improvement. I am not sure about other three changes
adding any value, though.
> Consider the ::before part a suggestion. I think it helps show the
> target line, but it does overlap the first character of any line >999.
Actually, when viewing the blame view, this is even worse, as it
seems to always overlap. The background color ought to be enough
cue without being overly distracting, I would have to say.
Jakub? Comments on any other points I may have missed?
>
> I've tested this on the browsers I have access to, which excludes
> Internet Explorer. Since it's cosmetic it shouldn't matter if it doesn't
> work.
>
> Wikipedia use similar CSS for their citation links:
> <http://en.wikipedia.org/wiki/Git_(software)#cite_note-1>
>
> gitweb/static/gitweb.css | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
> index cb86d2d..9f54311 100644
> --- a/gitweb/static/gitweb.css
> +++ b/gitweb/static/gitweb.css
> @@ -546,6 +546,16 @@ a.linenr {
> text-decoration: none
> }
>
> +a.linenr:hover, a.linenr:target {
> + color: #444444;
> + background-color: #ff4;
> +}
> +
> +a.linenr:hover::before, a.linenr:target::before {
> + content: '⚓';
> + position: absolute;
> +}
> +
> a.rss_logo {
> float: right;
> padding: 3px 0px;
^ permalink raw reply
* Re: $PATH pollution and t9902-completion.sh
From: Torsten Bögershausen @ 2012-12-20 20:53 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Adam Spiers, git mailing list,
Torsten Bögershausen
In-Reply-To: <20121220200109.GC21785@sigill.intra.peff.net>
On 20.12.12 21:01, Jeff King wrote:
> +test_fully_contains () {
>> + sort "$1" >expect.sorted &&
>> + sort "$2" >actual.sorted &&
>> + test $(comm -23 expect.sorted actual.sorted | wc -l) = 0
>> +}
(Good to learn about the comm command, thanks )
What do we think about this:
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..82eeba7 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -62,12 +62,16 @@ test_completion ()
{
if test $# -gt 1
then
- printf '%s\n' "$2" >expected
+ printf '%s\n' "$2" | sort >expected.sorted
else
- sed -e 's/Z$//' >expected
+ sed -e 's/Z$//' | sort >expected.sorted
fi &&
run_completion "$1" &&
- test_cmp expected out
+ sort <out >actual.sorted &&
+ >empty &&
+ comm -23 expected.sorted actual.sorted >actual &&
+ test_cmp empty actual &&
+ rm empty actual
}
# Test __gitcomp.
^ permalink raw reply related
* Re: What's cooking in git.git (Dec 2012, #05; Tue, 18)
From: Junio C Hamano @ 2012-12-20 20:26 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121220195837.GB21785@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So our attempt for more compile-time safety may actually introduce a
> run-time bug. And it is a hard bug to find, as the preprocessor
> "magically" converts the error code into -1 without you being able to
> see it in the code.
>
> It would be safer to just unconditionally use the macros and drop the
> return values from the functions entirely, like the patch below
> (squashed on top of what is in jk/error-const-return). But it cannot
> work for error(), because the variadic nature means we need to restrict
> ourselves to __GNUC__.
While I like the general direction, I am not sure if we are OK with
the introduction of
> #undef config_error_nonbool
> -int config_error_nonbool(const char *var)
> +void config_error_nonbool(const char *var)
> {
> - return error("Missing value for '%s'", var);
> + error("Missing value for '%s'", var);
> }
a new, arguably false, "returned value not used" warning from this
point. Perhaps it is fine for now, as we have tons of calls that do
not cast the return value to "(void)".
^ permalink raw reply
* Re: [PATCH] oneway_merge(): only lstat() when told to update worktree
From: Junio C Hamano @ 2012-12-20 20:02 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <1356025067-5396-1-git-send-email-martinvonz@gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> Although the subject line of 613f027 (read-tree -u one-way merge fix
> to check out locally modified paths., 2006-05-15) mentions "read-tree
> -u", it did not seem to check whether -u was in effect. Not checking
> whether -u is in effect makes e.g. "read-tree --reset" lstat() the
> worktree, even though the worktree stat should not matter for that
> operation.
>
> This speeds up e.g. "git reset" a little on the linux-2.6 repo (best
> of five, warm cache):
>
> Before After
> real 0m0.288s 0m0.233s
> user 0m0.190s 0m0.150s
> sys 0m0.090s 0m0.080s
> ---
Sign-off?
I briefly discussed this with Martin in person and came to the same
conclusion. To me this looks like an obvious performance fix, but an
independent code audit catches our mistakes is of course welcomed.
Thanks.
> I am very unfamiliar with this part of git, so my attempt at a
> motivation may be totally off.
>
> I have another twenty-or-so patches to reset.c coming up that take the
> timings down to around 90 ms, but this patch was quite unrelated to
> that. Those other patches actually make this patch pointless for "git
> reset" (it takes another path), but I hope this is still a good change
> for other operations that use oneway_merge.
>
> unpack-trees.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 6d96366..61acc5e 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -1834,7 +1834,7 @@ int oneway_merge(struct cache_entry **src, struct unpack_trees_options *o)
>
> if (old && same(old, a)) {
> int update = 0;
> - if (o->reset && !ce_uptodate(old) && !ce_skip_worktree(old)) {
> + if (o->reset && o->update && !ce_uptodate(old) && !ce_skip_worktree(old)) {
> struct stat st;
> if (lstat(old->name, &st) ||
> ie_match_stat(o->src_index, old, &st, CE_MATCH_IGNORE_VALID|CE_MATCH_IGNORE_SKIP_WORKTREE))
^ permalink raw reply
* Re: $PATH pollution and t9902-completion.sh
From: Jeff King @ 2012-12-20 20:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Spiers, git mailing list
In-Reply-To: <7vobho4hxa.fsf@alter.siamese.dyndns.org>
On Thu, Dec 20, 2012 at 11:55:45AM -0800, Junio C Hamano wrote:
> The beginning of such a change may look like the attached patch.
> [...]
> +test_fully_contains () {
> + sort "$1" >expect.sorted &&
> + sort "$2" >actual.sorted &&
> + test $(comm -23 expect.sorted actual.sorted | wc -l) = 0
> +}
I like the direction. I suspect test_fully_contains could be used in a
lot of other places, too.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2012, #05; Tue, 18)
From: Jeff King @ 2012-12-20 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwqwc617y.fsf@alter.siamese.dyndns.org>
On Thu, Dec 20, 2012 at 10:13:37AM -0800, Junio C Hamano wrote:
> >> * jk/error-const-return (2012-12-15) 2 commits
> >> - silence some -Wuninitialized false positives
> >> - make error()'s constant return value more visible
> >>
> >> Help compilers' flow analysis by making it more explicit that
> >> error() always returns -1, to reduce false "variable used
> >> uninitialized" warnings.
> >>
> >> This is still an RFC.
> >
> > What's your opinion on this?
>
> Ugly but not too much so, and it would be useful.
>
> The only thing that makes it ugly is that it promises error() will
> return -1 and nothing else forever, but at this point in the
> evolution of the codebase, I think we are pretty much committed to
> it anyway, so I do not think it is a problem.
Right. I do not mind saying "error() will always return -1" and forcing
somebody who changes that assumption to update the macro. But what
worries me is that when they make that update, there is no compile-time
check that indicates the macro and the function are no longer in sync.
So our attempt for more compile-time safety may actually introduce a
run-time bug. And it is a hard bug to find, as the preprocessor
"magically" converts the error code into -1 without you being able to
see it in the code.
It would be safer to just unconditionally use the macros and drop the
return values from the functions entirely, like the patch below
(squashed on top of what is in jk/error-const-return). But it cannot
work for error(), because the variadic nature means we need to restrict
ourselves to __GNUC__.
diff --git a/cache.h b/cache.h
index 0e8e5d8..694b146 100644
--- a/cache.h
+++ b/cache.h
@@ -1135,10 +1135,8 @@ extern int config_error_nonbool(const char *);
extern int check_repository_format_version(const char *var, const char *value, void *cb);
extern int git_env_bool(const char *, int);
extern int git_config_system(void);
-extern int config_error_nonbool(const char *);
-#ifdef __GNUC__
+extern void config_error_nonbool(const char *);
#define config_error_nonbool(s) (config_error_nonbool(s), -1)
-#endif
extern const char *get_log_output_encoding(void);
extern const char *get_commit_output_encoding(void);
diff --git a/config.c b/config.c
index 526f682..a22e78c 100644
--- a/config.c
+++ b/config.c
@@ -1661,7 +1661,7 @@ int config_error_nonbool(const char *var)
* get a boolean value (i.e. "[my] var" means "true").
*/
#undef config_error_nonbool
-int config_error_nonbool(const char *var)
+void config_error_nonbool(const char *var)
{
- return error("Missing value for '%s'", var);
+ error("Missing value for '%s'", var);
}
diff --git a/parse-options.c b/parse-options.c
index 67e98a6..ba39dd9 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -586,11 +586,12 @@ int opterror(const struct option *opt, const char *reason, int flags)
}
#undef opterror
-int opterror(const struct option *opt, const char *reason, int flags)
+void opterror(const struct option *opt, const char *reason, int flags)
{
if (flags & OPT_SHORT)
- return error("switch `%c' %s", opt->short_name, reason);
+ error("switch `%c' %s", opt->short_name, reason);
if (flags & OPT_UNSET)
- return error("option `no-%s' %s", opt->long_name, reason);
- return error("option `%s' %s", opt->long_name, reason);
+ error("option `no-%s' %s", opt->long_name, reason);
+ else
+ error("option `%s' %s", opt->long_name, reason);
}
diff --git a/parse-options.h b/parse-options.h
index e703853..bd43314 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -176,10 +176,8 @@ extern int opterror(const struct option *opt, const char *reason, int flags);
const struct option *options);
extern int optbug(const struct option *opt, const char *reason);
-extern int opterror(const struct option *opt, const char *reason, int flags);
-#ifdef __GNUC__
+extern void opterror(const struct option *opt, const char *reason, int flags);
#define opterror(o,r,f) (opterror((o),(r),(f)), -1)
-#endif
/*----- incremental advanced APIs -----*/
^ permalink raw reply related
* Re: $PATH pollution and t9902-completion.sh
From: Junio C Hamano @ 2012-12-20 19:55 UTC (permalink / raw)
To: Jeff King; +Cc: Adam Spiers, git mailing list
In-Reply-To: <7vk3sc606f.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> 2. Loosen the test to look for the presence of "checkout", but not
>> fail when other items are present. Bonus points if it makes sure
>> that everything returned starts with "check".
>>
>> I think (2) is the ideal solution in terms of behavior, but writing it
>> may be more of a pain.
>
> Yeah, I think (2) is the way to go.
The beginning of such a change may look like the attached patch.
If we want to go for the bonus points, we would either add another
parameter "prefix" to the test_completion function, or introduce the
test_complete_command function that takes that prefix parameter, and
in addition to making sure lines from "expect" is fully contained in
the "actual", make sure that output from
comm -13 expect.sorted actual.sorted
all begin with that "prefix" string, perhaps with
grep -v "^$prefix"
or something. The test_fully_contains function needs to be renamed
if somebody goes that additional step.
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..5fab389 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -54,10 +54,16 @@ run_completion ()
__git_wrap__git_main && print_comp
}
+test_fully_contains () {
+ sort "$1" >expect.sorted &&
+ sort "$2" >actual.sorted &&
+ test $(comm -23 expect.sorted actual.sorted | wc -l) = 0
+}
+
# Test high-level completion
# Arguments are:
# 1: typed text so far (cur)
-# 2: expected completion
+# 2: expected completion (if missing, this is read from stdin)
test_completion ()
{
if test $# -gt 1
@@ -67,7 +73,7 @@ test_completion ()
sed -e 's/Z$//' >expected
fi &&
run_completion "$1" &&
- test_cmp expected out
+ test_fully_contains expected out
}
# Test __gitcomp.
^ permalink raw reply related
* Re: [PATCH v6 0/7] make test output coloring more intuitive
From: Jeff King @ 2012-12-20 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Spiers, git list
In-Reply-To: <7vy5gs4jiy.fsf@alter.siamese.dyndns.org>
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 two categories. Either you already
> know you choose to not to care (e.g. I do not expect to use git-p4
> and decided not to install p4 anywhere, so I may have t98?? on
> GIT_SKIP_TESTS environment) or you haven't reached that point on a
> new system and haven't realized that you didn't install a package
> needed to run tests you care about (e.g. cvsserver tests would not
> run without Perl interface to SQLite). For the former, the bold
> output is merely distracting; for the latter, bold _might_ help in
> this case.
>
> At least, I think
>
> GIT_SKIP_TESTS=t98?? sh t9800-git-p4-basic.sh -v
>
> should paint "skipping test t9800 altogether" (emitted with "-v) and
> the last line "1..0 # SKIP skip all tests in t9800" both in the same
> "info" color.
>
> How about going further to reduce "bold" a bit more, like this?
Yeah, I think it is a little easier on the eyes while maintaining the
intended color scheme.
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index aaf013e..2bbb81d 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -182,13 +182,13 @@ then
> error)
> tput bold; tput setaf 1;; # bold red
> skip)
> - tput bold; tput setaf 4;; # bold blue
> + tput setaf 4;; # bold blue
On my xterm, at least, this is actually the difference between light
blue" and dark blue, not bold and not-bold. I think it is OK, though to
be honest, having seen the "skip all" messages in cyan (e.g., running
t9800), I think just printing skip messages in cyan looks best. But it
is not that big a deal to me, and we are well into bikeshed territory, I
think, so that will be my last word on the subject.
-Peff
^ permalink raw reply
* Re: [PATCH v6 0/7] make test output coloring more intuitive
From: Junio C Hamano @ 2012-12-20 19:21 UTC (permalink / raw)
To: Jeff King; +Cc: Adam Spiers, git list
In-Reply-To: <20121220161110.GA10605@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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 with the above squashed. Or even just said "I like
> this, please squash it into patch 4 (change info messages from
> yellow/brown to bold cyan).
Surely; as long as the series is not in 'next', the change to be
squashed is not too big and it is not too much work (and in this
case it certainly is not).
I actually wonder if "skipped test in bold blue" and "known breakage
in bold yellow" should also lose the boldness. Errors and warnings
in bold are good, but I would say the degree of need for attention
are more like this:
error (failed tests - you should look into it)
skip (skipped - perhaps you need more packages?)
warn (expected failure - you may want to look into fixing it someday)
info
pass
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 two categories. Either you already
know you choose to not to care (e.g. I do not expect to use git-p4
and decided not to install p4 anywhere, so I may have t98?? on
GIT_SKIP_TESTS environment) or you haven't reached that point on a
new system and haven't realized that you didn't install a package
needed to run tests you care about (e.g. cvsserver tests would not
run without Perl interface to SQLite). For the former, the bold
output is merely distracting; for the latter, bold _might_ help in
this case.
At least, I think
GIT_SKIP_TESTS=t98?? sh t9800-git-p4-basic.sh -v
should paint "skipping test t9800 altogether" (emitted with "-v) and
the last line "1..0 # SKIP skip all tests in t9800" both in the same
"info" color.
How about going further to reduce "bold" a bit more, like this?
diff --git a/t/test-lib.sh b/t/test-lib.sh
index aaf013e..2bbb81d 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -182,13 +182,13 @@ then
error)
tput bold; tput setaf 1;; # bold red
skip)
- tput bold; tput setaf 4;; # bold blue
+ tput setaf 4;; # bold blue
warn)
- tput bold; tput setaf 3;; # bold brown/yellow
+ tput setaf 3;; # bold brown/yellow
pass)
tput setaf 2;; # green
info)
- tput bold; tput setaf 6;; # bold cyan
+ tput setaf 6;; # bold cyan
*)
test -n "$quiet" && return;;
esac
@@ -589,7 +589,7 @@ for skp in $GIT_SKIP_TESTS
do
case "$this_test" in
$skp)
- say_color skip >&3 "skipping test $this_test altogether"
+ say_color info >&3 "skipping test $this_test altogether"
skip_all="skip all tests in $this_test"
test_done
esac
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox