* Re: [PATCH v7 2/7] tests: paint known breakages in yellow
From: Junio C Hamano @ 2012-12-21 15:46 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git, Adam Spiers, Jeff King
In-Reply-To: <50D4230F.9080502@gmail.com>
Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> On 12/21/2012 04:12 AM, Junio C Hamano wrote:
>> From: Adam Spiers <git@adamspiers.org>
>>
>> Yellow seems a more appropriate color than bold green when
>> considering the universal traffic lights coloring scheme, where
>> green conveys the impression that everything's OK, and amber that
>> something's not quite right.
>>
> Here are few more details about the behaviour of other testing
> tools, in case you want to squash them in the commit message for
> future references:
>
> 1. Automake (at least up to 1.13) and Autotest (at least up to the
> 2.69 Autoconf release) use "bold" green for reporting expected
> failures.
>
> 2. On the other hand, the 'prove' utility (as of TAP::Harness v3.23
> and Perl v5.14.2) use yellow (not bold) for the same purpose.
Nice to know, thanks.
I re-read the above three times, trying to see how to add it to the
log message, but having hard time phrasing it.
The only thing the additional knowledge adds seems to be to give
rationale for the old choice of "bold green"---it was not chosen
from thin-air but can be viewed as following the automake/autotest
scheme, and other systems cannot agree on what color to pick for
this purpose.
I do not see a need to justify why we chose differently from
automake/autotest; we could say something like:
Yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where
green conveys the impression that everything's OK, and amber that
something's not quite right. This is in line with what 'prove'
uses, but different from 'automake/autotest' do.
but we are not in the business of choosing which is more correct
between prove and automake/autotest, and I do not see how it adds
much value to tell readers that color choices are not universally
agreed upon across various test software suites---that's kind of
known, isn't it?
So...
^ permalink raw reply
* git diff --ignore-space-at-eol issue
From: John Moon @ 2012-12-21 15:04 UTC (permalink / raw)
To: git
Hi all,
The --ignore-space-at-eol option is ignored when used in conjunction
with --name-status.
It works fine otherwise.
$ git init
Initialized empty Git repository in /tmp/test/.git/
$ printf "hello\r\n" > test.txt
$git -c core.autocrlf=false add test.txt
$git commit -m.
[master (root-commit) 5c4ce92] .
1 file changed, 1 insertion(+)
create mode 100644 test.txt
$ printf "hello" > test.txt
$ git diff --ignore-space-at-eol test.txt
$ git diff --stat --ignore-space-at-eol test.txt
0 files changed
$ git diff --name-status --ignore-space-at-eol test.txt
M test.txt
Thanks.
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Yngve Nysaeter Pettersen @ 2012-12-21 15:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <50D468E6.2090900@drmicha.warpmail.net>
On Fri, 21 Dec 2012 14:49:26 +0100, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Yngve Nysaeter Pettersen venit, vidit, dixit 21.12.2012 13:43:
>> Hi,
>>
>> On Fri, 21 Dec 2012 13:23:46 +0100, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>
>>> Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
>>> 18.12.2012 15:51:
>>>> Hello all,
>>>>
>>>> Today Opera Software released the "Git-splitter", a small tool for
>>>> sub-modularizing code in a git repo, with complete commit history,
>>>> under
>>>> the Apache 2.0 license.
>>>>
>>>> It's functionality is similar to "git-subtree", but also include a
>>>> command
>>>> for reversing the process.
>>>
>>> Is there something keeping you technically from adding a join command
>>> to
>>> git-subtree?
>>
>> Probably not, but within the process I was working I did not want to
>> merge
>> the branch with the recreated history for that path into the existing
>> codebase (I don't like duplicate histories) so I used rebasing to move
>> the
>> new commits over, instead, and therefore did not need a join command.
>>
>> Feel free to add a join command, if you want one.
>
> Im sorry, but that was a total misunderstanding. You said git-splitter
> is like git-subtree but adds a command for reversing the process. My
> question was: What kept you from adding that to git-subtree (rather than
> redoing stiff that git-subtree does)?
>
> I just assumed that reversing the process of splitting must be joining.
>
> It may very well be that git-splitter does things differently, i.e. that
> there are more differences than just added functionality (compared to
> git-subtree), but that is not clear from the announcement.
The split command will create a new repository for all files foo in a
folder (path/foo) and their commit history.
The replant command reverses that process, re-adding the path prefix for
each file. It may be possible to extend that process into one that
automatically reintegrates the new commits in the original history, but I
never had time to complete that work.
I did originally add the "replant" functionality into my version of the
git-subtree script, but given the number of commits in the original
repository, git-subtree turned out to be inefficient, due to the use of
temporary files (tens of thousands of files IIRC).
Those problems led to my development of git-splitter in Python (bypassing
the problem of temporary files), but just including the functionality I
needed, join was not one of those functions.
>>>> The code is hosted on GitHub:
>>>> <https://github.com/operasoftware/git-splitter>
>>>>
>>>> We have announced the release as part of another announcement of
>>>> released
>>>> code at the Opera Security Group home page:
>>>> <http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
>>>>
>>
>>
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 96 90 41 51 Fax: +47 23 69 24 01
********************************************************************
^ permalink raw reply
* Installation Plan
From: Dennis Putnam @ 2012-12-21 14:43 UTC (permalink / raw)
To: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
After re-reading the git documentation and with Andrew's input I have
changed my thinking on how to set this up and want a central
repository. If I understand correctly, I am doing builds while I am
developing new code so I need to clone my repository for Eclipse (I'm
assuming the git plugin supports all this). Before I go to the trouble
of setting it up please correct where my thinking is flawed or where I
may run into gotchas.
1) Install git on Linux.
2) Copy existing Eclipse project to a new directory to become the
central repository.
3) git init in that new directory (I think I then do a git add and git
commit).
4) Modify build scripts to build from that directory (I am guessing I
need to git ignore the javac generated binary directory).
5) Install git plugin on Windows version of Eclipse. (Do I need git on
Windows or is the plugin sufficient?)
6) Configure plugin for remote git, if necessary?
7) Clone new repository for development and testing on Windows. (Do I
need the shared drive any more?)
8) When a new version is ready for release, push commit to remote
repository after which builds will use new code (I'm assuming the file
copies happen automagically).
Am I over simplifying things? I also think that this will open the door
for collaborators in the event I need them with no changes to the way I
work. I should note that builds are done on demand so is there a way to
detect when a push is occurring and have the build script wait for
completion and I suppose vise-versa? Thanks.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* recommendation for patch maintenance
From: Manlio Perillo @ 2012-12-21 14:45 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
I would like to have advices about some possible workflows to use when
maintaining a patch, that can evolve over the time (fixing bugs, and
applying advices from reviewers).
In my case I have a single commit to maintain.
The workflow I use now is this:
1) create a topic branch, e.g. mp/complete-path
2) write code
3) commit
4) format-patch --output=mp/complete-patch master
5) review the patch
6) send-email
when I need to update the patch:
1) modify code
2) commit --amend
3) format-patch --subject-prefix="PATCH v<n>" \
--output=mp/complete-patch master
4) edit patch to add a list of what was changed
5) review the patch
6) send-email
This is far from ideal, since all my local changes are lost.
Another problem is that when I found some trivial error in 5), I need to
call format-patch again, loosing the "what's changed list".
A possible solution is to:
1) create a "public" topic branch, e.g. mp/complete-patch
2) create the associated "private" topic branch, e.g.
mp/complete-patch/private
...
Changes are committed to the private branch.
When I need to update the patch:
1) update code
2) commit new changes; the commit message will contain the
"what's changed" list to be used for the new version of the patch
3) checkout <public branch>
4) merge --squash <private branch>
Now I have my full history, and the "what's changed list" is saved in
the private commits.
(not tested)
What is the workflow you usually use?
Thanks Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDUde4ACgkQscQJ24LbaUSqOwCfZON5f9mdAYkvACim802JGFhP
5W8An1Y7WXgsH/Q/p1/0jVMo1dJ3HwwO
=Xydn
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Noob Question
From: W T Riker @ 2012-12-21 13:27 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <CAH5451kq8XwPTez0Jhst+rVCo=EteW7OMH4wr2a1rCXTW_f0jQ@mail.gmail.com>
Hi Andrew,
Thank you for a great explanation. It clears up a number of things but
also creates some new questions. However, armed with this I am going to
run through the documentation again and perhaps it will make more sense
to me. One basic question, since I don't make changes from the Linux
side, only builds, do I need to install anything git related on that
machine?
On 12/20/2012 8:43 PM, Andrew Ardill wrote:
> 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
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Michael J Gruber @ 2012-12-21 13:49 UTC (permalink / raw)
To: Yngve Nysaeter Pettersen; +Cc: git
In-Reply-To: <op.wpn2xz07vqd7e2@damia.oslo.osa>
Yngve Nysaeter Pettersen venit, vidit, dixit 21.12.2012 13:43:
> Hi,
>
> On Fri, 21 Dec 2012 13:23:46 +0100, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>
>> Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
>> 18.12.2012 15:51:
>>> Hello all,
>>>
>>> Today Opera Software released the "Git-splitter", a small tool for
>>> sub-modularizing code in a git repo, with complete commit history, under
>>> the Apache 2.0 license.
>>>
>>> It's functionality is similar to "git-subtree", but also include a
>>> command
>>> for reversing the process.
>>
>> Is there something keeping you technically from adding a join command to
>> git-subtree?
>
> Probably not, but within the process I was working I did not want to merge
> the branch with the recreated history for that path into the existing
> codebase (I don't like duplicate histories) so I used rebasing to move the
> new commits over, instead, and therefore did not need a join command.
>
> Feel free to add a join command, if you want one.
Im sorry, but that was a total misunderstanding. You said git-splitter
is like git-subtree but adds a command for reversing the process. My
question was: What kept you from adding that to git-subtree (rather than
redoing stiff that git-subtree does)?
I just assumed that reversing the process of splitting must be joining.
It may very well be that git-splitter does things differently, i.e. that
there are more differences than just added functionality (compared to
git-subtree), but that is not clear from the announcement.
>>> The code is hosted on GitHub:
>>> <https://github.com/operasoftware/git-splitter>
>>>
>>> We have announced the release as part of another announcement of
>>> released
>>> code at the Opera Security Group home page:
>>> <http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
>>>
>
>
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Michael J Gruber @ 2012-12-21 12:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Yann Dirson, Andreas Schwab, Christian Couder,
git list, Jeff King
In-Reply-To: <7vvcbx956f.fsf@alter.siamese.dyndns.org>
While replace refs are much more general than grafts, it seems the two
main uses are:
- grafts (change the recorded parents for a commit)
- svn cleanup (convert tagging commits into tag objects)
The latter one being quite a special case already.
The script below has helped me move from grafts to replace objects.
While not being super clean, something like it may be fit for contrib.
I think we ought to help John Doe get along with parents, while we can
safely leave most more advanced operations to people who know how to
edit a raw object file. Putting that facility into "git-commit" seems to
be too encouraging, though - people would use replace when they should
use amend or rebase-i. I'd prefer a special git-replace mode (be it
"--graft" or "--graft-commit") which does just what my script does. We
could add things like "--commit-tag" later, a full blown
"object-factory" seems like overkill.
Michael
--->%---
#!/bin/sh
die () {
echo "$@"
rm -f "$commitfile"
exit 1
}
warn () {
echo "$@"
}
test $# -gt 0 || die "Usage: $0 <commit> [<parent>]*"
for commit
do
git rev-parse --verify -q "$commit" >/dev/null || die "Cannot parse
$commit."
test x$(git cat-file -t $commit) == "xcommit" || die "$commit is no
commit."
done
commit="$1"
shift
commitfile=$(mktemp)
git cat-file commit "$commit" | while read a b
do
if test "$a" != "parent"
then
echo $a $b
fi
if test "$a" == "tree"
then
for parent
do
echo "parent $(git rev-parse $parent)"
done
fi
done >$commitfile
hash=$(git hash-object -t commit -w "$commitfile") || die "Cannot create
commit object."
git replace "$commit" $hash
rm -f $commitfile
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Yngve Nysaeter Pettersen @ 2012-12-21 12:43 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <50D454D2.5030403@drmicha.warpmail.net>
Hi,
On Fri, 21 Dec 2012 13:23:46 +0100, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
> 18.12.2012 15:51:
>> Hello all,
>>
>> Today Opera Software released the "Git-splitter", a small tool for
>> sub-modularizing code in a git repo, with complete commit history, under
>> the Apache 2.0 license.
>>
>> It's functionality is similar to "git-subtree", but also include a
>> command
>> for reversing the process.
>
> Is there something keeping you technically from adding a join command to
> git-subtree?
Probably not, but within the process I was working I did not want to merge
the branch with the recreated history for that path into the existing
codebase (I don't like duplicate histories) so I used rebasing to move the
new commits over, instead, and therefore did not need a join command.
Feel free to add a join command, if you want one.
>> The code is hosted on GitHub:
>> <https://github.com/operasoftware/git-splitter>
>>
>> We have announced the release as part of another announcement of
>> released
>> code at the Opera Security Group home page:
>> <http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
>>
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 96 90 41 51 Fax: +47 23 69 24 01
********************************************************************
^ permalink raw reply
* Re: [PATCH] builtin/clean.c: Fix some sparse warnings
From: Zoltan Klinger @ 2012-12-21 12:31 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <50D35A13.9080605@ramsay1.demon.co.uk>
Thanks, Ramsay. I am rewriting the whole patch to do things a better
way (as kindly suggested by Junio). So the print_filtered() function
is going to disappear, but thanks for pointing out the problems with
the existing code.
Cheers,
Zoltan
On 21 December 2012 05:33, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>
> Sparse issues two "Using plain integer as NULL pointer" warnings
> (lines 41 and 47).
>
> The first warning relates to the initializer expression in the
> declaration for the 'char *dir' variable. In order to suppress
> the warning, we simply replace the zero initializer with NULL.
>
> The second warning relates to an expression, as part of an if
> conditional, using the equality operator to compare the 'dir'
> variable to zero. In order to suppress the warning, we replace
> the 'dir == 0' expression with the more idiomatic '!dir'.
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
>
> Hi Zoltan,
>
> If you have already updated your patch and made this redundant
> (it's been a few days since I read the list or fetched git.git),
> please ignore this. Otherwise, could you please squash this into
> the new version of commit 16e4033e6 ("git-clean: Display more
> accurate delete messages", 17-12-2012).
>
> [BTW, in the same conditional expression you have an strncmp()
> call which doesn't quite follow the style/conventions of the
> existing code.]
>
> Thanks!
>
> ATB,
> Ramsay Jones
>
> builtin/clean.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/clean.c b/builtin/clean.c
> index 1c25a75..0c603c8 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -38,13 +38,13 @@ static void print_filtered(const char *msg, struct string_list *lst)
> {
> int i;
> char *name;
> - char *dir = 0;
> + char *dir = NULL;
>
> sort_string_list(lst);
>
> for (i = 0; i < lst->nr; i++) {
> name = lst->items[i].string;
> - if (dir == 0 || strncmp(name, dir, strlen(dir)) != 0)
> + if (!dir || strncmp(name, dir, strlen(dir)) != 0)
> printf("%s %s\n", msg, name);
> if (name[strlen(name) - 1] == '/')
> dir = name;
> --
> 1.8.0
>
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Michael J Gruber @ 2012-12-21 12:23 UTC (permalink / raw)
To: Yngve N. Pettersen (Developer Opera Software ASA); +Cc: git
In-Reply-To: <op.wpiovoj5qrq7tp@acorna.invalid.invalid>
Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
18.12.2012 15:51:
> Hello all,
>
> Today Opera Software released the "Git-splitter", a small tool for
> sub-modularizing code in a git repo, with complete commit history, under
> the Apache 2.0 license.
>
> It's functionality is similar to "git-subtree", but also include a command
> for reversing the process.
Is there something keeping you technically from adding a join command to
git-subtree?
> The code is hosted on GitHub:
> <https://github.com/operasoftware/git-splitter>
>
> We have announced the release as part of another announcement of released
> code at the Opera Security Group home page:
> <http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
>
^ permalink raw reply
* Re: [PATCH v8 1/3] submodule: add get_submodule_config helper funtion
From: W. Trevor King @ 2012-12-21 11:04 UTC (permalink / raw)
To: Heiko Voigt
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121221082033.GB560@book.hvoigt.net>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
On Fri, Dec 21, 2012 at 09:20:33AM +0100, Heiko Voigt wrote:
> On Wed, Dec 19, 2012 at 11:03:31AM -0500, wking@tremily.us wrote:
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index 2365149..263a60c 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -153,6 +153,32 @@ die_if_unmatched ()
> [...]
> > +get_submodule_config () {
> > + name="$1"
> > + option="$2"
> > + default="$3"
> > + value=$(git config submodule."$name"."$option")
> > + if test -z "$value"
> > + then
> > + value=$(git config -f .gitmodules submodule."$name"."$option")
> > + fi
> > + printf '%s' "${value:-$default}"
> > +}
> > +
> > +
> > +#
>
> Minor nit: For all other functions we only have one newline as
> separator.
I'm fine rerolling this, or Junio can make the change on my behalf, or
it can be left as is ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Eric S. Raymond @ 2012-12-21 10:44 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <50D4199C.6000002@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> In 2009 I added tests demonstrating some of the erroneous behavior of
> git-cvsimport. The failing tests in t9601-t9603 are concrete examples
> of the problems mentioned in the manpage.
Thanks, that will be extremely useful. One of the things I'm putting effort
into is building a good test suite for the tool; I may well be able to adapt
your tests directly.
>
> If you haven't yet seen it, there is a writeup of the algorithm used by
> cvs2git to infer the history of a CVS repository [1]. If your goal is
> to make cvsps more robust, you might want to consider the ideas
> described there.
I shall do so. Their design ideas may well be interesting, even though I
don't trust their code. I've seem cvs2svn drop far too many weird artifacts
and just plain broken commits in the back history of Subversion repositories.
I don't know if this is due to design problems, implementation bugs, or both.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH v7 0/7] coloring test output after traffic signal
From: Adam Spiers @ 2012-12-21 10:00 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20121221081521.GA22193@sigill.intra.peff.net>
On Fri, Dec 21, 2012 at 8:15 AM, Jeff King <peff@peff.net> 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.
Great, thanks a lot Junio.
> Thanks, this looks OK to me.
To me too.
> And thank you, Adam, for your patience. Seven iterations of color
> bikeshedding is more than should be asked of anyone. :)
;-)
^ permalink raw reply
* Re: [PATCH v7 2/7] tests: paint known breakages in yellow
From: Stefano Lattarini @ 2012-12-21 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adam Spiers, Jeff King
In-Reply-To: <1356059558-23479-3-git-send-email-gitster@pobox.com>
On 12/21/2012 04:12 AM, Junio C Hamano wrote:
> From: Adam Spiers <git@adamspiers.org>
>
> Yellow seems a more appropriate color than bold green when
> considering the universal traffic lights coloring scheme, where
> green conveys the impression that everything's OK, and amber that
> something's not quite right.
>
Here are few more details about the behaviour of other testing
tools, in case you want to squash them in the commit message for
future references:
1. Automake (at least up to 1.13) and Autotest (at least up to the
2.69 Autoconf release) use "bold" green for reporting expected
failures.
2. On the other hand, the 'prove' utility (as of TAP::Harness v3.23
and Perl v5.14.2) use yellow (not bold) for the same purpose.
Regards,
Stefano
^ permalink raw reply
* Re: [PATCH v8 1/3] submodule: add get_submodule_config helper funtion
From: Heiko Voigt @ 2012-12-21 8:20 UTC (permalink / raw)
To: wking
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <3377beb925bc209d90058493b74d174db1b7aa50.1355932282.git.wking@tremily.us>
On Wed, Dec 19, 2012 at 11:03:31AM -0500, wking@tremily.us wrote:
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2365149..263a60c 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -153,6 +153,32 @@ die_if_unmatched ()
[...]
> +get_submodule_config () {
> + name="$1"
> + option="$2"
> + default="$3"
> + value=$(git config submodule."$name"."$option")
> + if test -z "$value"
> + then
> + value=$(git config -f .gitmodules submodule."$name"."$option")
> + fi
> + printf '%s' "${value:-$default}"
> +}
> +
> +
> +#
Minor nit: For all other functions we only have one newline as
separator.
Cheers Heiko
^ permalink raw reply
* Re: [PATCH v8 0/3] submodule update: add --remote for submodule's upstream changes
From: Heiko Voigt @ 2012-12-21 8:18 UTC (permalink / raw)
To: wking
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <cover.1355932282.git.wking@tremily.us>
Hi,
On Wed, Dec 19, 2012 at 11:03:30AM -0500, wking@tremily.us wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> Comments on v7 seem to have petered out, so here's v8. Changes since
> v7:
>
> * Series based on gitster/master instead of v1.8.0.
> * In Documentation/config.txt, restored trailing line of
> submodule.<name>.update documentation, which I had accidentally
> removed in v7.
> * In Documentation/git-submodule.txt, make --no-fetch example in the
> --remote description more general, following Phil's suggestion.
> * In git-submodule.sh:
> * Remove accidental "ges" line.
> * Use the submodule's default remote to determine which tracking
> branch to fetch. In v7 I'd been using the superproject's default
> remote.
> * In cmd_add(), use sm_name instead of sm_path to store the --branch
> option (catching up with 73b0898).
Sorry, I was not able to follow the discussion that closely lately but I
like the outcome. For me there is nothing to change or add functionality
wise. Thanks.
Cheers Heiko
^ permalink raw reply
* Re: [PATCH v7 0/7] coloring test output after traffic signal
From: Jeff King @ 2012-12-21 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adam Spiers
In-Reply-To: <1356059558-23479-1-git-send-email-gitster@pobox.com>
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, for your patience. Seven iterations of color
bikeshedding is more than should be asked of anyone. :)
-Peff
^ permalink raw reply
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Michael Haggerty @ 2012-12-21 8:11 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121220215638.E54BC44119@snark.thyrsus.com>
On 12/20/2012 10:56 PM, Eric S. Raymond wrote:
> 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.
> [...] I have added a --fast-export option to
> cvsps-3.0 that emits a git fast-import stream representing the CVS
> history.
> [...]
> 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.
In 2009 I added tests demonstrating some of the erroneous behavior of
git-cvsimport. The failing tests in t9601-t9603 are concrete examples
of the problems mentioned in the manpage.
If you haven't yet seen it, there is a writeup of the algorithm used by
cvs2git to infer the history of a CVS repository [1]. If your goal is
to make cvsps more robust, you might want to consider the ideas
described there.
Michael
[1] File doc/design-notes.txt in the cvs2svn source tree, also visible here:
http://cvs2svn.tigris.org/source/browse/*checkout*/cvs2svn/trunk/doc/design-notes.txt
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH] refs: do not use cached refs in repack_without_ref
From: Jeff King @ 2012-12-21 8:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
When we delete a ref that is packed, we rewrite the whole
packed-refs file and simply omit the ref that no longer
exists. However, we base the rewrite on whatever happens to
be in our refs cache, not what is necessarily on disk. That
opens us up to a race condition if another process is
simultaneously packing the refs, as we will overwrite their
newly-made pack-refs file with our potentially stale data,
losing commits.
You can demonstrate the race like this:
# setup some repositories
git init --bare parent &&
(cd parent && git config core.logallrefupdates true) &&
git clone parent child &&
(cd child && git commit --allow-empty -m base)
# in one terminal, repack the refs repeatedly
cd parent &&
while true; do
git pack-refs --all
done
# in another terminal, simultaneously push updates to
# master, and create and delete an unrelated ref
cd child &&
while true; do
git push origin HEAD:newbranch &&
git commit --allow-empty -m foo
us=`git rev-parse master` &&
git push origin master &&
git push origin :newbranch &&
them=`git --git-dir=../parent rev-parse master` &&
if test "$them" != "$us"; then
echo >&2 "$them" != "$us"
exit 1
fi
done
In many cases the two processes will conflict over locking
the packed-refs file, and the deletion of newbranch will
simply fail. But eventually you will hit the race, which
happens like this:
1. We push a new commit to master. It is already packed
(from the looping pack-refs call). We write the new
value (let us call it B) to $GIT_DIR/refs/heads/master,
but the old value (call it A) remains in the
packed-refs file.
2. We push the deletion of newbranch, spawning a
receive-pack process. Receive-pack advertises all refs
to the client, causing it to iterate over each ref; it
caches the packed refs in memory, which points at the
stale value A.
3. Meanwhile, a separate pack-refs process is running. It
runs to completion, updating the packed-refs file to
point master at B, and deleting $GIT_DIR/refs/heads/master
which also pointed at B.
4. Back in the receive-pack process, we get the
instruction to delete :newbranch. We take a lock on
packed-refs (which works, as the other pack-refs
process has already finished). We then rewrite the
contents using the cached refs, which contain the stale
value A.
The resulting packed-refs file points master once again at
A. The loose ref which would override it to point at B was
deleted (rightfully) in step 3. As a result, master now
points at A. The only trace that B ever existed in the
parent is in the reflog: the final entry will show master
moving from A to B, even though the ref still points at A
(so you can detect this race after the fact, because the
next reflog entry will move from A to C).
We can fix this by invalidating the packed-refs cache after
we have taken the lock. This means that we will re-read the
packed-refs file, and since we have the lock, we will be
sure that what we read will be atomically up-to-date when we
write (it may be out of date with respect to loose refs, but
that is OK, as loose refs take precedence).
Signed-off-by: Jeff King <peff@peff.net>
---
We actually see this in practice on GitHub, though it is relatively
rare (I've been chasing reports for a while, and in a very busy repo, it
can happen every couple of weeks; this is probably due to the fact that
we run "git gc" very frequently).
There are a few other interesting races in this code that this does not
fix:
1. We check to see whether the ref is packed based on the cached data.
That means that in the following sequence:
a. receive-pack starts, caches packed refs; master is not packed
b. meanwhile, pack-refs runs and packs master
c. receive-pack deletes the loose ref for master (which might be
a no-op if the pack-refs from (b) got there first). It checks
its cached packed-refs and sees that there is nothing to
delete.
We end up leaving the entry in packed-refs. In other words, the
deletion does not actually delete anything, but it still returns
success.
We could fix this by scanning the list of packed refs only after
we've acquired the lock. The downside is that this would increase
lock contention on packed-refs.lock. Right now, two deletions may
conflict if they are deletions of packed refs. With this change,
any two deletions might conflict, packed or not.
If we work under the assumption that deletions are relatively rare,
this is probably OK. And if you tend to keep your refs packed, it
would not make any difference. It would have an impact on repos
which do not pack refs, and which have frequent simultaneous
deletions.
2. The delete_ref function first deletes the loose ref, then rewrites
the packed-refs file. This means that for a moment, the ref may
appear to have rewound to whatever was in the packed-refs file, and
the reader has no way of knowing.
This is not a huge deal, but I think it could be fixed by swapping
the ordering. However, I think that would open us up to the reverse
race from above: we delete from packed-refs, then before we delete
the loose ref, a pack-refs process repacks it. Our deletion looks
successful, but the ref remains afterwards.
I fixed just the race I did because it does not (as far as I can tell)
have any downsides. And it is way more severe (the other ones are "a
deleted ref might come back", whereas the fixed one will actually lose
commits).
refs.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 6cec1c8..541fec2 100644
--- a/refs.c
+++ b/refs.c
@@ -1744,7 +1744,8 @@ static int repack_without_ref(const char *refname)
static int repack_without_ref(const char *refname)
{
struct repack_without_ref_sb data;
- struct ref_dir *packed = get_packed_refs(get_ref_cache(NULL));
+ struct ref_cache *refs = get_ref_cache(NULL);
+ struct ref_dir *packed = get_packed_refs(refs);
if (find_ref(packed, refname) == NULL)
return 0;
data.refname = refname;
@@ -1753,6 +1754,8 @@ static int repack_without_ref(const char *refname)
unable_to_lock_error(git_path("packed-refs"), errno);
return error("cannot delete '%s' from packed refs", refname);
}
+ clear_packed_ref_cache(refs);
+ packed = get_packed_refs(refs);
do_for_each_ref_in_dir(packed, 0, "", repack_without_ref_fn, 0, 0, &data);
return commit_lock_file(&packlock);
}
--
1.8.1.rc2.6.g05591da
^ permalink raw reply related
* RE: Python version auditing followup
From: Joachim Schmitz @ 2012-12-21 7:26 UTC (permalink / raw)
To: 'Junio C Hamano'; +Cc: git
In-Reply-To: <7vzk182yka.fsf@alter.siamese.dyndns.org>
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Thursday, December 20, 2012 10:39 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: Python version auditing followup
>
> "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 one port was done" to me.
Well, not entirely wrong, but not all true at too.
I guess I need to defend the vendor here: It is not really the Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3, it
is a volunteer and community effort. HP did sponsor the 2.4.2 port though (by allowing an HP employee to do the port inn his regular
working hours). It is not doing this any longer (since 2007). Since then it is a small group doing this on a purely voluntary basis
in their spare time (one HP employee amongst them, me).
Same goes for the git port BTW. And for every other port provided on http://ituglib.connect-cummunity.org (this machine is sponsored
by HP).
Almost every other port, as some pretty recently made it into the officially supported O/S version, so far: Samba, bash, coreutils,
vim, gzip, bzip2, Perl, PHP.
Bye, Jojo
^ permalink raw reply
* [PATCH v2] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
From: David Aguilar @ 2012-12-21 6:57 UTC (permalink / raw)
To: Junio C Hamano, Jeremy Morton; +Cc: git
Use $TMPDIR when creating the /dev/null placeholder for p4merge.
This keeps it out of the current directory.
Reported-by: Jeremy Morton <admin@game-point.net>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
No mktemp usage in this round.
mergetools/p4merge | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 295361a..52f7c8f 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -1,29 +1,21 @@
diff_cmd () {
+ empty_file=
+
# p4merge does not like /dev/null
- rm_local=
- rm_remote=
if test "/dev/null" = "$LOCAL"
then
- LOCAL="./p4merge-dev-null.LOCAL.$$"
- >"$LOCAL"
- rm_local=true
+ LOCAL="$(create_empty_file)"
fi
if test "/dev/null" = "$REMOTE"
then
- REMOTE="./p4merge-dev-null.REMOTE.$$"
- >"$REMOTE"
- rm_remote=true
+ REMOTE="$(create_empty_file)"
fi
"$merge_tool_path" "$LOCAL" "$REMOTE"
- if test -n "$rm_local"
- then
- rm -f "$LOCAL"
- fi
- if test -n "$rm_remote"
+ if test -n "$empty_file"
then
- rm -f "$REMOTE"
+ rm -f "$empty_file"
fi
}
@@ -33,3 +25,10 @@ merge_cmd () {
"$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
check_unchanged
}
+
+create_empty_file () {
+ empty_file="${TMPDIR:-/tmp}/git-difftool-p4merge-empty-file.$$"
+ >"$empty_file"
+
+ printf "$empty_file"
+}
--
1.8.1.rc2.6.g18499ba
^ permalink raw reply related
* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Junio C Hamano @ 2012-12-21 3:38 UTC (permalink / raw)
To: esr; +Cc: Jeff King, git
In-Reply-To: <7vsj7060nj.fsf@alter.siamese.dyndns.org>
I needed something like this on top of it to get it pass t5800.
diff --git a/git_remote_helpers/git/__init__.py b/git_remote_helpers/git/__init__.py
index 776e891..5047fd4 100644
--- a/git_remote_helpers/git/__init__.py
+++ b/git_remote_helpers/git/__init__.py
@@ -1,3 +1,5 @@
+import sys
+
if sys.hexversion < 0x02040000:
# The limiter is the subprocess module
sys.stderr.write("git_remote_helpers: requires Python 2.4 or later.")
--
1.8.1.rc2.225.g0e05fff
^ permalink raw reply related
* [PATCH v7 6/7] tests: test the test framework more thoroughly
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>
From: Adam Spiers <git@adamspiers.org>
Add 5 new full test suite runs each with a different number of
passing/failing/broken/fixed tests, in order to ensure that the
correct exit code and output are generated in each case. As before,
these are run in a subdirectory to avoid disrupting the metrics for
the parent tests.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t0000-basic.sh | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index d0f46e8..384b0ae 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -89,6 +89,56 @@ check_sub_test_lib_test () {
)
}
+test_expect_success 'pretend we have a fully passing test suite' "
+ run_sub_test_lib_test full-pass '3 passing tests' <<-\\EOF &&
+ for i in 1 2 3
+ do
+ test_expect_success \"passing test #\$i\" 'true'
+ done
+ test_done
+ EOF
+ check_sub_test_lib_test full-pass <<-\\EOF
+ > ok 1 - passing test #1
+ > ok 2 - passing test #2
+ > ok 3 - passing test #3
+ > # passed all 3 test(s)
+ > 1..3
+ EOF
+"
+
+test_expect_success 'pretend we have a partially passing test suite' "
+ test_must_fail run_sub_test_lib_test \
+ partial-pass '2/3 tests passing' <<-\\EOF &&
+ test_expect_success 'passing test #1' 'true'
+ test_expect_success 'failing test #2' 'false'
+ test_expect_success 'passing test #3' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test partial-pass <<-\\EOF
+ > ok 1 - passing test #1
+ > not ok 2 - failing test #2
+ # false
+ > ok 3 - passing test #3
+ > # failed 1 among 3 test(s)
+ > 1..3
+ EOF
+"
+
+test_expect_success 'pretend we have a known breakage' "
+ run_sub_test_lib_test failing-todo 'A failing TODO test' <<-\\EOF &&
+ test_expect_success 'passing test' 'true'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_done
+ EOF
+ check_sub_test_lib_test failing-todo <<-\\EOF
+ > ok 1 - passing test
+ > not ok 2 - pretend we have a known breakage # TODO known breakage
+ > # still have 1 known breakage(s)
+ > # passed all remaining 1 test(s)
+ > 1..2
+ EOF
+"
+
test_expect_success 'pretend we have fixed a known breakage' "
run_sub_test_lib_test passing-todo 'A passing TODO test' <<-\\EOF &&
test_expect_failure 'pretend we have fixed a known breakage' 'true'
@@ -102,6 +152,61 @@ test_expect_success 'pretend we have fixed a known breakage' "
EOF
"
+test_expect_success 'pretend we have a pass, fail, and known breakage' "
+ test_must_fail run_sub_test_lib_test \
+ mixed-results1 'mixed results #1' <<-\\EOF &&
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'failing test' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_done
+ EOF
+ check_sub_test_lib_test mixed-results1 <<-\\EOF
+ > ok 1 - passing test
+ > not ok 2 - failing test
+ > # false
+ > not ok 3 - pretend we have a known breakage # TODO known breakage
+ > # still have 1 known breakage(s)
+ > # failed 1 among remaining 2 test(s)
+ > 1..3
+ EOF
+"
+
+test_expect_success 'pretend we have a mix of all possible results' "
+ test_must_fail run_sub_test_lib_test \
+ mixed-results2 'mixed results #2' <<-\\EOF &&
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'failing test' 'false'
+ test_expect_success 'failing test' 'false'
+ test_expect_success 'failing test' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_failure 'pretend we have fixed a known breakage' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test mixed-results2 <<-\\EOF
+ > ok 1 - passing test
+ > ok 2 - passing test
+ > ok 3 - passing test
+ > ok 4 - passing test
+ > not ok 5 - failing test
+ > # false
+ > not ok 6 - failing test
+ > # false
+ > not ok 7 - failing test
+ > # false
+ > not ok 8 - pretend we have a known breakage # TODO known breakage
+ > not ok 9 - pretend we have a known breakage # TODO known breakage
+ > ok 10 - pretend we have fixed a known breakage # TODO known breakage
+ > # fixed 1 known breakage(s)
+ > # still have 2 known breakage(s)
+ > # failed 3 among remaining 8 test(s)
+ > 1..10
+ EOF
+"
+
test_set_prereq HAVEIT
haveit=no
test_expect_success HAVEIT 'test runs if prerequisite is satisfied' '
--
1.8.1.rc2.225.g8d36ab4
^ permalink raw reply related
* [PATCH v7 7/7] tests: paint unexpectedly fixed known breakages in bold red
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>
From: Adam Spiers <git@adamspiers.org>
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this is
an error which is potentially as bad as a failing test, and as such is
no longer portrayed as a pass in the output.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t0000-basic.sh | 30 ++++++++++++++++++++++++------
t/test-lib.sh | 13 +++++++++----
2 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 384b0ae..8973d2c 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -145,13 +145,31 @@ test_expect_success 'pretend we have fixed a known breakage' "
test_done
EOF
check_sub_test_lib_test passing-todo <<-\\EOF
- > ok 1 - pretend we have fixed a known breakage # TODO known breakage
- > # fixed 1 known breakage(s)
- > # passed all 1 test(s)
+ > ok 1 - pretend we have fixed a known breakage # TODO known breakage vanished
+ > # 1 known breakage(s) vanished; please update test(s)
> 1..1
EOF
"
+test_expect_success 'pretend we have fixed one of two known breakages (run in sub test-lib)' "
+ run_sub_test_lib_test partially-passing-todos \
+ '2 TODO tests, one passing' <<-\\EOF &&
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_success 'pretend we have a passing test' 'true'
+ test_expect_failure 'pretend we have fixed another known breakage' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test partially-passing-todos <<-\\EOF
+ > not ok 1 - pretend we have a known breakage # TODO known breakage
+ > ok 2 - pretend we have a passing test
+ > ok 3 - pretend we have fixed another known breakage # TODO known breakage vanished
+ > # 1 known breakage(s) vanished; please update test(s)
+ > # still have 1 known breakage(s)
+ > # passed all remaining 1 test(s)
+ > 1..3
+ EOF
+"
+
test_expect_success 'pretend we have a pass, fail, and known breakage' "
test_must_fail run_sub_test_lib_test \
mixed-results1 'mixed results #1' <<-\\EOF &&
@@ -199,10 +217,10 @@ test_expect_success 'pretend we have a mix of all possible results' "
> # false
> not ok 8 - pretend we have a known breakage # TODO known breakage
> not ok 9 - pretend we have a known breakage # TODO known breakage
- > ok 10 - pretend we have fixed a known breakage # TODO known breakage
- > # fixed 1 known breakage(s)
+ > ok 10 - pretend we have fixed a known breakage # TODO known breakage vanished
+ > # 1 known breakage(s) vanished; please update test(s)
> # still have 2 known breakage(s)
- > # failed 3 among remaining 8 test(s)
+ > # failed 3 among remaining 7 test(s)
> 1..10
EOF
"
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 8b75c9a..30a0937 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -278,7 +278,7 @@ test_failure_ () {
test_known_broken_ok_ () {
test_fixed=$(($test_fixed+1))
- say_color "" "ok $test_count - $@ # TODO known breakage"
+ say_color error "ok $test_count - $@ # TODO known breakage vanished"
}
test_known_broken_failure_ () {
@@ -373,13 +373,18 @@ test_done () {
if test "$test_fixed" != 0
then
- say_color pass "# fixed $test_fixed known breakage(s)"
+ say_color error "# $test_fixed known breakage(s) vanished; please update test(s)"
fi
if test "$test_broken" != 0
then
say_color warn "# still have $test_broken known breakage(s)"
- msg="remaining $(($test_count-$test_broken)) test(s)"
+ fi
+ if test "$test_broken" != 0 || test "$test_fixed" != 0
+ then
+ test_remaining=$(( $test_count - $test_broken - $test_fixed ))
+ msg="remaining $test_remaining test(s)"
else
+ test_remaining=$test_count
msg="$test_count test(s)"
fi
case "$test_failure" in
@@ -393,7 +398,7 @@ test_done () {
if test $test_external_has_tap -eq 0
then
- if test $test_count -gt 0
+ if test $test_remaining -gt 0
then
say_color pass "# passed all $msg"
fi
--
1.8.1.rc2.225.g8d36ab4
^ 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