Re: [PATCH] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder

[David Aguilar]

On Wed, Dec 19, 2012 at 10:28 PM, Junio C Hamano  wrote:
> David Aguilar  writes:
>
>> Use mktemp to create the /dev/null placeholder for p4merge.
>> This keeps it out of the current directory.
>>
>> Reported-by: Jeremy Morton 
>> Signed-off-by: David Aguilar 
>> ---
>> I consider this a final finishing touch on a new 1.8.1 feature,
>> so hopefully we can get this in before 1.8.1.
>
> Does everybody have mktemp(1), which is not even in POSIX.1?
>
> I'm a bit hesitant to apply this to the upcoming release without
> cooking it in 'next' for sufficiently long time to give it a chance
> to be tried by wider audience.

True.  I only tried Linux and Mac OS X, so I would not be
surprised to find some exotic UNIX that does not have mktemp.

I meant to write "is this portable?" in the section after
the double-dash; saying that it's polish for a fix
is only true if it's portable.

The git-unpack thing looks interesting...
is the SHA-1 in your example the special SHA-1 for an
empty tree or blob?

The reason I ask is because in this code path we are
comparing an unknown blob, basically a blob that does
not exist in one of the trees, so I'm not sure if an
'unpack' command would help for this case because we
would not have a blob SHA-1 to unpack.


As far as portability goes, the "UNIX" list
for p4merge is here:

http://www.perforce.com/downloads/complete_list

I do not have AIX, Solaris, or FreeBSD to test,
so I agree that this can wait.

Does msysgit have mktemp?

p4merge is available on Windows too so I would
need to check there too unless someone happens
to know off the top of their heads.

My other thought was to write a simple shell
function that checks TMPDIR itself, and defaults
to creating some file under /tmp when it is undefined.
I can pursue this option if you think it's a safer choice.
-- 
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder

[Joachim Schmitz]

Junio C Hamano wrote:

David Aguilar  writes:


Use mktemp to create the /dev/null placeholder for p4merge.
This keeps it out of the current directory.

Reported-by: Jeremy Morton 
Signed-off-by: David Aguilar 
---
I consider this a final finishing touch on a new 1.8.1 feature,
so hopefully we can get this in before 1.8.1.


Does everybody have mktemp(1), which is not even in POSIX.1?


HP-NonStop doesn't have it, unless you're on the latest release, which added 
GNU coreutils.


Bye, Jojo 



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] Convert all fnmatch() calls to wildmatch()

[Nguyen Thai Ngoc Duy]

On Thu, Dec 20, 2012 at 1:36 AM, Junio C Hamano  wrote:
>> @@ -627,7 +628,7 @@ enum interesting tree_entry_interesting(const struct 
>> name_entry *entry,
>>   return entry_interesting;
>>
>>   if (item->use_wildcard) {
>> - if (!fnmatch(match + baselen, entry->path, 0))
>> + if (!wildmatch(match + baselen, entry->path, 
>> 0))
>>   return entry_interesting;
>
> This and the change to dir.c obviously have interactions with
> 8c6abbc (pathspec: apply "*.c" optimization from exclude,
> 2012-11-24).
>
> I've already alluded to it in my response to 2/3, I guess.

Conflict of plans. I did not expect myself to work on replacing
fnmatch soon and git_fnmatch is an intermediate step to collect more
optimizations and gradually replace fnmatch. Eventually git_fnmatch()
would become a wrapper of wildmatch, all the optimizations are pushed
down there. If we replace fnmatch->wildmatch first then there's little
reason for the existence of git_fnmatch(). Maybe I should merge this
with the fnmatch elimination into a single series.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] wildmatch: support "no FNM_PATHNAME" mode

[Nguyen Thai Ngoc Duy]

On Thu, Dec 20, 2012 at 8:55 AM, Nguyen Thai Ngoc Duy  wrote:
>> As long as simpler patterns fnmatch() groks (namely, '?', '*', and
>> '[class]' wildcards only) are not slowed down by replacing it with
>> wildmatch(), that is, of course.
>
> I'm concerned about performance vs fnmatch too. I'll probably write a
> small program to exercise both and measure it with glibc.

I'll send out proper patches later this weekend, but unless I make big
mistakes it seems wildmatch is faster than fnmatch from glibc 2.14.1
on x86-64 :) Maybe I did make mistakes. The test matches every line in
/tmp/filelist.txt (which is ls-files from linux-2.6.git) 2000 times.
"pathname" means FNM_PATHNAME.

$ export LANG=C
$ ./test-wildmatch-perf /tmp/filelist.txt 'Documentation/*' 2000
wildmatch 1s 528394us
fnmatch   2s 588396us
$ ./test-wildmatch-perf /tmp/filelist.txt 'drivers/*' 2000
wildmatch 1s 957243us
fnmatch   3s 134839us
$ ./test-wildmatch-perf /tmp/filelist.txt 'Documentation/*' 2000 pathname
wildmatch 1s 548575us
fnmatch   2s 629680us
$ ./test-wildmatch-perf /tmp/filelist.txt 'drivers/*' 2000 pathname
wildmatch 2s 142377us
fnmatch   3s 318295us
$ ./test-wildmatch-perf /tmp/filelist.txt '[Dd]ocu[Mn]entation/*' 2000
wildmatch 1s 748505us
fnmatch   3s 224414us
$ ./test-wildmatch-perf /tmp/filelist.txt '[Dd]o?u[Mn]en?ati?n/*' 2000
wildmatch 1s 743268us
fnmatch   3s 278034us
$ ./test-wildmatch-perf /tmp/filelist.txt '[Dd]o?u[Mn]en?ati?n/*' 2000 pathname
wildmatch 1s 745151us
fnmatch   3s 314127us
$ ./test-wildmatch-perf /tmp/filelist.txt nonsense 2000 pathname
wildmatch 1s 310727us
fnmatch   2s 279123us
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Gitweb running as FCGI does not print its output in UTF-8

[Sergio Talens-Oliag]

Hello, I'm sending this message to explain a problem I've found with
gitweb.cgi when running it using a call like the following:

export FCGI_SOCKET_PATH="/run/gitweb.socket"
gitweb.cgi --fcgi --nproc 2

I've fixed the problem for my installation usign a wrapper script, as
explained below.

I'm not sending a patch because I'm no expert in Perl and I'm unsure that
the solution I've found is the right one, but in the hope that my description
of the problem and the provided solution will be useful for others.

Problem description:

   When using gitweb.cgi in FCGI mode the answers from the script are returned
   using the wrong encoding (UTF-8 characters are printed as LATIN-1).
   
   It seems that the problem appears because the FCGI streams are implemented
   using the older stream API, TIEHANDLE and applying PerlIO layers using
   binmode() has no effect to them.

Applied solution:

   A solution similar to the use of binmode for the output stream is to
   redefine the FCGI::Stream::PRINT function to use UTF-8 as output encoding.

   To do it with minimal chages I've created a gitweb.cgi wrapper that
   redefines the function and runs the original script; I'm doing it like this
   to be able to use the packaged script until upstream includes a fix for the
   problem.

Wrapper code (uses /usr/share/gitweb/gitweb.cgi as the PATH for gitweb.cgi):

  #!/usr/bin/perl
  # gitweb.cgi wrapper that fixes the UTF-8 problem with fastcgi

  # Local redefinition of FCGI::Stream::PRINT
  use Encode;
  use FCGI;

  our $enc = Encode::find_encoding('UTF-8');
  our $org = \&FCGI::Stream::PRINT;
  no warnings 'redefine';

  local *FCGI::Stream::PRINT = sub {
my @OUTPUT = @_;
for (my $i = 1; $i < @_; $i++) {
  $OUTPUT[$i] = $enc->encode($_[$i], Encode::FB_CROAK|Encode::LEAVE_SRC);
}
@_ = @OUTPUT;
goto $org;
  };

  # Execute original script
  do "/usr/share/gitweb/gitweb.cgi";

References:

   The applied solution has been found on the following StackOverflow
   question:

 http://stackoverflow.com/questions/5005104

Environment:

  The system I'm using is Debian Wheezy and I'm serving gitweb using nginx's
  fastcgi interface.

  The versions of the related debian packages are:
  
Package: git
Version: 1:1.7.10.4-1+wheezy1
Package: libcgi-fast-perl
Version: 5.14.2-16
Package: libfcgi-procmanager-perl
Version: 0.24-1
Package: perl
Version: 5.14.2-16

  To launch gitweb as fastcgi I'm using an init.d script that runs the wrapper
  script in the background as the `www-user` using a call similar to the
  following:

export FCGI_SOCKET_PATH="/run/gitweb/socket"
gitweb.cgi-wrapper --fcgi --nproc 2

Greetings,

  Sergio.

-- 
Sergio Talens-Oliag
Key fingerprint = FF77 A16B 9D09 FC7B 6656 CFAD 261D E19A 578A 36F2


signature.asc
Description: Digital signature

[PATCH] Python scripts audited for minimum compatible version and checks added.

[Eric S. Raymond]

Signed-off-by: Eric S. Raymond 
---
 contrib/ciabot/ciabot.py   | 5 +
 contrib/fast-import/import-zips.py | 5 +
 contrib/hg-to-git/hg-to-git.py | 5 +
 contrib/p4import/git-p4import.py   | 5 +
 contrib/svn-fe/svnrdump_sim.py | 4 
 git-p4.py  | 5 +
 git-remote-testgit.py  | 5 +
 git_remote_helpers/git/__init__.py | 4 
 8 files changed, 38 insertions(+)

diff --git a/contrib/ciabot/ciabot.py b/contrib/ciabot/ciabot.py
index bd24395..b55648f 100755
--- a/contrib/ciabot/ciabot.py
+++ b/contrib/ciabot/ciabot.py
@@ -50,6 +50,11 @@
 import os, sys, commands, socket, urllib
 from xml.sax.saxutils import escape
 
+if sys.hexversion < 0x0200:
+   # The limiter is the xml.sax module
+sys.stderr.write("import-zips.py: requires Python 2.0.0 or later.")
+sys.exit(1)
+
 # Changeset URL prefix for your repo: when the commit ID is appended
 # to this, it should point at a CGI that will display the commit
 # through gitweb or something similar. The defaults will probably
diff --git a/contrib/fast-import/import-zips.py 
b/contrib/fast-import/import-zips.py
index 82f5ed3..d9ad71d 100755
--- a/contrib/fast-import/import-zips.py
+++ b/contrib/fast-import/import-zips.py
@@ -13,6 +13,11 @@ from sys import argv, exit
 from time import mktime
 from zipfile import ZipFile
 
+if sys.hexversion < 0x0106:
+   # The limiter is the zipfile module
+sys.stderr.write("import-zips.py: requires Python 1.6.0 or later.")
+sys.exit(1)
+
 if len(argv) < 2:
print 'Usage:', argv[0], '...'
exit(1)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 046cb2b..9f39ce5 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -23,6 +23,11 @@ import os, os.path, sys
 import tempfile, pickle, getopt
 import re
 
+if sys.hexversion < 0x0203:
+   # The behavior of the pickle module changed significantly in 2.3
+   sys.stderr.write("hg-to-git.py: requires Python 2.3 or later.")
+   sys.exit(1)
+
 # Maps hg version -> git version
 hgvers = {}
 # List of children for each hg revision
diff --git a/contrib/p4import/git-p4import.py b/contrib/p4import/git-p4import.py
index b6e534b..fb48e2a 100644
--- a/contrib/p4import/git-p4import.py
+++ b/contrib/p4import/git-p4import.py
@@ -14,6 +14,11 @@ import sys
 import time
 import getopt
 
+if sys.hexversion < 0x0202:
+   # The behavior of the marshal module changed significantly in 2.2
+   sys.stderr.write("git-p4import.py: requires Python 2.2 or later.")
+   sys.exit(1)
+
 from signal import signal, \
SIGPIPE, SIGINT, SIG_DFL, \
default_int_handler
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
index 1cfac4a..ed43dbb 100755
--- a/contrib/svn-fe/svnrdump_sim.py
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -7,6 +7,10 @@ to the highest revision that should be available.
 """
 import sys, os
 
+if sys.hexversion < 0x0204:
+   # The limiter is the ValueError() calls. This may be too conservative
+sys.stderr.write("svnrdump-sim.py: requires Python 2.4 or later.")
+sys.exit(1)
 
 def getrevlimit():
 var = 'SVNRMAX'
diff --git a/git-p4.py b/git-p4.py
index 551aec9..ec060b4 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -12,6 +12,11 @@ import optparse, sys, os, marshal, subprocess, shelve
 import tempfile, getopt, os.path, time, platform
 import re, shutil
 
+if sys.hexversion < 0x0204:
+# The limiter is the subprocess module
+sys.stderr.write("git-p4.py: requires Python 2.4 or later.")
+sys.exit(1)
+
 verbose = False
 
 # Only labels/tags matching this will be imported/exported
diff --git a/git-remote-testgit.py b/git-remote-testgit.py
index 5f3ebd2..22d2eb6 100644
--- a/git-remote-testgit.py
+++ b/git-remote-testgit.py
@@ -31,6 +31,11 @@ from git_remote_helpers.git.exporter import GitExporter
 from git_remote_helpers.git.importer import GitImporter
 from git_remote_helpers.git.non_local import NonLocalGit
 
+if sys.hexversion < 0x01050200:
+# os.makedirs() is the limiter
+sys.stderr.write("git-remote-testgit.py: requires Python 1.5.2 or later.")
+sys.exit(1)
+
 def get_repo(alias, url):
 """Returns a git repository object initialized for usage.
 """
diff --git a/git_remote_helpers/git/__init__.py 
b/git_remote_helpers/git/__init__.py
index e69de29..776e891 100644
--- a/git_remote_helpers/git/__init__.py
+++ b/git_remote_helpers/git/__init__.py
@@ -0,0 +1,4 @@
+if sys.hexversion < 0x0204:
+# The limiter is the subprocess module
+sys.stderr.write("git_remote_helpers: requires Python 2.4 or later.")
+sys.exit(1)
-- 
1.8.1.rc2



-- 
http://www.catb.org/~esr/";>Eric S. Raymond

"The state calls its own violence `law', but that of the individual `crime'"
-- Max Stirner
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Mor

Python version auditing followup

[Eric S. Raymond]

Most of the Python scripts in the distribution are small and simple to
audit, so I am pretty sure of the results.  The only place where I
have a concern is the git_helpers library; that is somewhat more
complex and I might have missed a dependency somewhere.  Whoever
owns that should check my finding that it should run under 2.4

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?
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

In recent years it has been suggested that the Second Amendment
protects the "collective" right of states to maintain militias, while
it does not protect the right of "the people" to keep and bear arms.
If anyone entertained this notion in the period during which the
Constitution and the Bill of Rights were debated and ratified, it
remains one of the most closely guarded secrets of the eighteenth
century, for no known writing surviving from the period between 1787
and 1791 states such a thesis.
-- Stephen P. Halbrook, "That Every Man Be Armed", 1984
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Python scripts audited for minimum compatible version and checks added.

[Jeff King]

On Thu, Dec 20, 2012 at 09:13:37AM -0500, Eric S. Raymond wrote:

> diff --git a/contrib/ciabot/ciabot.py b/contrib/ciabot/ciabot.py
> index bd24395..b55648f 100755
> --- a/contrib/ciabot/ciabot.py
> +++ b/contrib/ciabot/ciabot.py
> @@ -50,6 +50,11 @@
>  import os, sys, commands, socket, urllib
>  from xml.sax.saxutils import escape
>  
> +if sys.hexversion < 0x0200:
> + # The limiter is the xml.sax module
> +sys.stderr.write("import-zips.py: requires Python 2.0.0 or later.")
> +sys.exit(1)

Should the error message say ciabot.py?

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: $PATH pollution and t9902-completion.sh

[Jeff King]

On Mon, Dec 17, 2012 at 01:05:38AM +, Adam Spiers wrote:

> t/t9902-completion.sh is currently failing for me because I happen to
> have a custom shell-script called git-check-email in ~/bin, which is
> on my $PATH.  This is different to a similar-looking case reported
> recently, which was due to an unclean working tree:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/208085
> 
> It's not unthinkable that in the future other tests could break for
> similar reasons.  Therefore it would be good to sanitize $PATH in the
> test framework so that it cannot destabilize tests, although I am
> struggling to think of a good way of doing this.  Naively stripping
> directories under $HOME would not protect against git "plugins" such
> as the above being installed into places like /usr/bin.  Thoughts?

I've run into this, too. I think sanitizing $PATH is the wrong approach.
The real problem is that the test is overly picky. Right now it is
failing because you happen to have "check-email" in your $PATH, but it
will also need to be adjusted when a true "check-email" command is added
to git.

I can think of two other options:

  1. Make the test input more specific (e.g., looking for "checkou").
 This doesn't eliminate the problem, but makes it less likely
 to occur.

  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.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Dec 2012, #05; Tue, 18)

[Jeff King]

On Tue, Dec 18, 2012 at 12:31:43PM -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? The last round I posted (and what you have
in pu) is about as good as this technique is going to get. So it is
really a taste thing. On the one hand, I really like that it is not just
papering over the problem, but rather giving the compiler more data to
do its analysis. On the other hand, it makes the source kind of ugly.

I don't think there's a rush on it, but I'm just sifting through my
half-done topics.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Python scripts audited for minimum compatible version and checks added.

[Eric S. Raymond]

Jeff King :
> On Thu, Dec 20, 2012 at 09:13:37AM -0500, Eric S. Raymond wrote:
> 
> > diff --git a/contrib/ciabot/ciabot.py b/contrib/ciabot/ciabot.py
> > index bd24395..b55648f 100755
> > --- a/contrib/ciabot/ciabot.py
> > +++ b/contrib/ciabot/ciabot.py
> > @@ -50,6 +50,11 @@
> >  import os, sys, commands, socket, urllib
> >  from xml.sax.saxutils import escape
> >  
> > +if sys.hexversion < 0x0200:
> > +   # The limiter is the xml.sax module
> > +sys.stderr.write("import-zips.py: requires Python 2.0.0 or later.")
> > +sys.exit(1)
> 
> Should the error message say ciabot.py?
> 
> -Peff

Gack.  Yes.  Thaty's what I get for cut-and-pasting too quickly.
The information about xnml.sex is correct, though.

Want me to resubmit, or will you just patch it?

Note by the way that I still think the entire ciabot subtree (which is 
my code) should just be nuked.  CIA is not coming back, wishful thinking 
on Ilkotech's web page notwithstanding.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: "git config -l" should not expose sensitive information

[Jeff King]

On Mon, Dec 17, 2012 at 12:35:54PM +0100, Toralf Förster wrote:

> often the output is requested in help forums - and a
> "git config -l | wgetpaste" exposes parameters like sendmail.smtppass -
> so hide those variables in the output (if not explicitly wanted) would
> makes sense, or ?

But if we change "git config -l", won't that break all of the
non-exposing uses that rely on seeing all of the variables (e.g., it is
perfectly fine for a porcelain to parse "git config -l" rather than
making several calls to "git config"; IIRC, git-cola does this).

The problem seems to be that people are giving bad advice to tell people
to post "git config -l" output without looking at. Maybe we could help
them with a "git config --share-config" option that dumps all config,
but sanitizes the output. It would need to have a list of sensitive keys
(which does not exist yet), and would need to not just mark up things
like smtppass, but would also need to pull credential information out of
remote.*.url strings. And maybe more (I haven't thought too long on it).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: $PATH pollution and t9902-completion.sh

[Adam Spiers]

On Thu, Dec 20, 2012 at 2:55 PM, Jeff King  wrote:
> On Mon, Dec 17, 2012 at 01:05:38AM +, Adam Spiers wrote:
>> t/t9902-completion.sh is currently failing for me because I happen to
>> have a custom shell-script called git-check-email in ~/bin, which is
>> on my $PATH.  This is different to a similar-looking case reported
>> recently, which was due to an unclean working tree:
>>
>>   http://thread.gmane.org/gmane.comp.version-control.git/208085
>>
>> It's not unthinkable that in the future other tests could break for
>> similar reasons.  Therefore it would be good to sanitize $PATH in the
>> test framework so that it cannot destabilize tests, although I am
>> struggling to think of a good way of doing this.  Naively stripping
>> directories under $HOME would not protect against git "plugins" such
>> as the above being installed into places like /usr/bin.  Thoughts?
>
> I've run into this, too. I think sanitizing $PATH is the wrong approach.
> The real problem is that the test is overly picky. Right now it is
> failing because you happen to have "check-email" in your $PATH, but it
> will also need to be adjusted when a true "check-email" command is added
> to git.
>
> I can think of two other options:
>
>   1. Make the test input more specific (e.g., looking for "checkou").
>  This doesn't eliminate the problem, but makes it less likely
>  to occur.
>
>   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.

I agree with all your points.  Thanks for the suggestions.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/7] make test output coloring more intuitive

[Jeff King]

On Sun, Dec 16, 2012 at 07:01:56PM +, Adam Spiers wrote:

> On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano  wrote:
> > Adam Spiers  writes:
> >
> >> This series of commits attempts to make test output coloring
> >> more intuitive,...
> >
> > Thanks; I understand that this is to replace the previous one
> > b465316 (tests: paint unexpectedly fixed known breakages in bold
> > red, 2012-09-19)---am I correct?
> 
> Correct.  AFAICS I have incorporated all feedback raised in previous
> reviews.
> 
> > Will take a look; thanks.
> 
> Thanks.  Sorry again for the delay.  I'm now (finally) resuming work
> on as/check-ignore.

I eyeballed the test output of "pu". I do think this resolves all of the
issues brought up before, and I really hate to bikeshed on the colors at
this point, but I find that bold cyan a bit hard on the eyes when
running with "-v" (where most of the output is in that color, as it
dumps the shell for each test).  Is there any reason not to tone it down
a bit like:

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 256f1c6..31f59af 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -227,7 +227,7 @@ then
pass)
tput setaf 2;;# green
info)
-   tput bold; tput setaf 6;; # bold cyan
+   tput setaf 6;; # cyan
*)
test -n "$quiet" && return;;
esac

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/7] make test output coloring more intuitive

[Adam Spiers]

On Thu, Dec 20, 2012 at 3:34 PM, Jeff King  wrote:
> On Sun, Dec 16, 2012 at 07:01:56PM +, Adam Spiers wrote:
>> On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano  wrote:
>> > Adam Spiers  writes:
>> >> This series of commits attempts to make test output coloring
>> >> more intuitive,...
>> >
>> > Thanks; I understand that this is to replace the previous one
>> > b465316 (tests: paint unexpectedly fixed known breakages in bold
>> > red, 2012-09-19)---am I correct?
>>
>> Correct.  AFAICS I have incorporated all feedback raised in previous
>> reviews.
>>
>> > Will take a look; thanks.
>>
>> Thanks.  Sorry again for the delay.  I'm now (finally) resuming work
>> on as/check-ignore.
>
> I eyeballed the test output of "pu". I do think this resolves all of the
> issues brought up before, and I really hate to bikeshed on the colors at
> this point, but I find that bold cyan a bit hard on the eyes when
> running with "-v" (where most of the output is in that color, as it
> dumps the shell for each test).  Is there any reason not to tone it down
> a bit like:
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 256f1c6..31f59af 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -227,7 +227,7 @@ then
> pass)
> tput setaf 2;;# green
> info)
> -   tput bold; tput setaf 6;; # bold cyan
> +   tput setaf 6;; # cyan
> *)
> test -n "$quiet" && return;;
> esac
>
> -Peff

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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: "git config -l" should not expose sensitive information

[Aaron Schrab]

At 10:04 -0500 20 Dec 2012, Jeff King  wrote:
The problem seems to be that people are giving bad advice to tell 
people to post "git config -l" output without looking at. Maybe we 
could help them with a "git config --share-config" option that dumps 
all config, but sanitizes the output. It would need to have a list of 
sensitive keys (which does not exist yet), and would need to not just 
mark up things like smtppass, but would also need to pull credential 
information out of remote.*.url strings. And maybe more (I haven't 
thought too long on it).


If such an option is added, it is likely to cause more people to think 
that there is no need to examine the output before sharing it.  But, I 
don't think that the sanitizing could ever be sufficient to guarantee 
that.


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.


Even for known sensitive keys, the person entering it might have made a 
typo in the name (e.g.  smptpass) preventing it from being recognized as 
sensitive by the software, but easily recognizable as such by a human.


There's also the problem of varying opinions on what is considered as 
sensitive.  You mention credential information in URLs, but some people 
may consider the entire URL as something which they would not want to 
expose.


I think that attempting to do this would only result in a false sense of 
security.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: "git config -l" should not expose sensitive information

[Michael Haggerty]

On 12/20/2012 04:04 PM, Jeff King wrote:
> On Mon, Dec 17, 2012 at 12:35:54PM +0100, Toralf Förster wrote:
>> often the output is requested in help forums - and a
>> "git config -l | wgetpaste" exposes parameters like sendmail.smtppass -
>> so hide those variables in the output (if not explicitly wanted) would
>> makes sense, or ?
> 
> But if we change "git config -l", won't that break all of the
> non-exposing uses that rely on seeing all of the variables (e.g., it is
> perfectly fine for a porcelain to parse "git config -l" rather than
> making several calls to "git config"; IIRC, git-cola does this).
> 
> The problem seems to be that people are giving bad advice to tell people
> to post "git config -l" output without looking at. Maybe we could help
> them with a "git config --share-config" option that dumps all config,
> but sanitizes the output. It would need to have a list of sensitive keys
> (which does not exist yet), and would need to not just mark up things
> like smtppass, but would also need to pull credential information out of
> remote.*.url strings. And maybe more (I haven't thought too long on it).

I think the problem is yet another step earlier: why do we build tools
that encourage people to store passwords in plaintext in a configuration
file that is by default world-readable?

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: "git config -l" should not expose sensitive information

[Jeff King]

On Thu, Dec 20, 2012 at 10:49:15AM -0500, Aaron Schrab wrote:

> At 10:04 -0500 20 Dec 2012, Jeff King  wrote:
> >The problem seems to be that people are giving bad advice to tell
> >people to post "git config -l" output without looking at. Maybe we
> >could help them with a "git config --share-config" option that
> >dumps all config, but sanitizes the output. It would need to have a
> >list of sensitive keys (which does not exist yet), and would need
> >to not just mark up things like smtppass, but would also need to
> >pull credential information out of remote.*.url strings. And maybe
> >more (I haven't thought too long on it).
> 
> If such an option is added, it is likely to cause more people to
> think that there is no need to examine the output before sharing it.
> But, I don't think that the sanitizing could ever be sufficient to
> guarantee that.
> 
> 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.

Good point. I was a little on the fence already because any time you
have a "prevent known bad" list in a security setting, it is guaranteed
to go out of date and screw you. But the presence of third-party tools
means it does not even have to get out of date. It will always be
complete.

> 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.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: "git config -l" should not expose sensitive information

[Jeff King]

On Thu, Dec 20, 2012 at 04:51:37PM +0100, Michael Haggerty wrote:

> > The problem seems to be that people are giving bad advice to tell people
> > to post "git config -l" output without looking at. Maybe we could help
> > them with a "git config --share-config" option that dumps all config,
> > but sanitizes the output. It would need to have a list of sensitive keys
> > (which does not exist yet), and would need to not just mark up things
> > like smtppass, but would also need to pull credential information out of
> > remote.*.url strings. And maybe more (I haven't thought too long on it).
> 
> I think the problem is yet another step earlier: why do we build tools
> that encourage people to store passwords in plaintext in a configuration
> file that is by default world-readable?

Agreed. Most of it is hysterical raisins. We did not have any portable
secure storage for a long time. These days we have the credential helper
subsystem, which send-email can and should be using.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/7] make test output coloring more intuitive

[Jeff King]

On Thu, Dec 20, 2012 at 03:44:53PM +, Adam Spiers wrote:

> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 256f1c6..31f59af 100644
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -227,7 +227,7 @@ then
> > pass)
> > tput setaf 2;;# green
> > info)
> > -   tput bold; tput setaf 6;; # bold cyan
> > +   tput setaf 6;; # cyan
> > *)
> > test -n "$quiet" && return;;
> > esac
> >
> 
> 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).

As an aside, it made me wonder how hard/useful it would be to color the
snippets even more. Doing this:

diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index f9ccbf2..3d44a94 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -364,7 +364,12 @@ test_expect_success () {
export test_prereq
if ! test_skip "$@"
then
-   say >&3 "expecting success: $2"
+   if test -z "$GIT_TEST_HIGHLIGHT"; then
+   say >&3 "expecting success: $2"
+   else
+   say >&3 "expecting success:"
+   echo "$2" | eval "$GIT_TEST_HIGHLIGHT"
+   fi
if test_run_ "$2"
then
test_ok_ "$1"

produces highlighted snippets with:

  GIT_TEST_HIGHLIGHT='highlight -S sh -O ansi'

or

  GIT_TEST_HIGHLIGHT='pygmentize -l sh'

depending on what you have installed on your system. I'm not convinced
it actually adds anything, but it's a fun toy. A real patch would
probably turn it off in non-verbose mode, as invoking the highlighter
(especially pygmentize) repeatedly is somewhat expensive.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: "git config -l" should not expose sensitive information

[Toralf Förster]

yep - understood


On 12/20/2012 04:49 PM, Aaron Schrab wrote:
> At 10:04 -0500 20 Dec 2012, Jeff King  wrote:
>> The problem seems to be that people are giving bad advice to tell
>> people to post "git config -l" output without looking at. Maybe we
>> could help them with a "git config --share-config" option that dumps
>> all config, but sanitizes the output. It would need to have a list of
>> sensitive keys (which does not exist yet), and would need to not just
>> mark up things like smtppass, but would also need to pull credential
>> information out of remote.*.url strings. And maybe more (I haven't
>> thought too long on it).
> 
> If such an option is added, it is likely to cause more people to think
> that there is no need to examine the output before sharing it.  But, I
> don't think that the sanitizing could ever be sufficient to guarantee that.
> 
> 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.
> 
> Even for known sensitive keys, the person entering it might have made a
> typo in the name (e.g.  smptpass) preventing it from being recognized as
> sensitive by the software, but easily recognizable as such by a human.
> 
> There's also the problem of varying opinions on what is considered as
> sensitive.  You mention credential information in URLs, but some people
> may consider the entire URL as something which they would not want to
> expose.
> 
> I think that attempting to do this would only result in a false sense of
> security.
> 


-- 
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] test: Old shells and physical paths

[David Michael]

Hi,

On Thu, Dec 20, 2012 at 12:01 AM, David Aguilar  wrote:
> Do you know if the differences are relegated to "cd",
> or do other common commands such as awk, grep, sed, mktemp, expr,
> etc. have similar issues?

There are almost certainly going to be incompatibilities with other
commands.  The system implemented UNIX95 plus some extensions, then
they began supporting UNIX03/SUSv3/POSIX.1-2001/whatever for certain
commands by using an environment variable to toggle between the
incompatible behaviors.

Their documentation on the UNIX03 commands indicates it is still only
partially supported.  For example: "cp" supports "-L" and "-P", but
"cd" doesn't.

> I wonder if it'd be helpful to have a low-numbered test that checks
> the basics needed by the scripted Porcelains and test suite.
> It would give us an easy way to answer these questions, and could
> be a good way to document (in code) the capabilities we expect.

I'd be in favor of something like this as well.

Thanks.

David


P.S.
In the meantime, I am handling the "cd" situation by replacing "-P"
with "$PHYS" and prepending the following to t/test-lib.sh.
set +o logical >/dev/null 2>&1 || PHYS=-P
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: $PATH pollution and t9902-completion.sh

[Torsten Bögershausen]

On 20.12.12 16:13, Adam Spiers wrote:
> On Thu, Dec 20, 2012 at 2:55 PM, Jeff King  wrote:
>> On Mon, Dec 17, 2012 at 01:05:38AM +, Adam Spiers wrote:
>>> t/t9902-completion.sh is currently failing for me because I happen to
>>> have a custom shell-script called git-check-email in ~/bin, which is
>>> on my $PATH.  This is different to a similar-looking case reported
>>> recently, which was due to an unclean working tree:
>>>
>>>   http://thread.gmane.org/gmane.comp.version-control.git/208085
>>>
>>> It's not unthinkable that in the future other tests could break for
>>> similar reasons.  Therefore it would be good to sanitize $PATH in the
>>> test framework so that it cannot destabilize tests, although I am
>>> struggling to think of a good way of doing this.  Naively stripping
>>> directories under $HOME would not protect against git "plugins" such
>>> as the above being installed into places like /usr/bin.  Thoughts?
>>
>> I've run into this, too. I think sanitizing $PATH is the wrong approach.
>> The real problem is that the test is overly picky. Right now it is
>> failing because you happen to have "check-email" in your $PATH, but it
>> will also need to be adjusted when a true "check-email" command is added
>> to git.
>>
>> I can think of two other options:
>>
>>   1. Make the test input more specific (e.g., looking for "checkou").
>>  This doesn't eliminate the problem, but makes it less likely
>>  to occur.
>>
>>   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.
> 
> I agree with all your points.  Thanks for the suggestions.
I volonteer for 1) (and we got for 2) later)



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] t9902: Be more specific when completing git-checkout

[Torsten Bögershausen]

t9902 is trying to complete e.g.
"git --version check" into "git --version checkout"

If there are other binaries like
"git-check-email" or "git-check-ignore" in the PATH
one test case failes

By using "checkou" instead of "check" the test becomes
more future proof.

Signed-off-by: Torsten Bögershausen 
---
 t/t9902-completion.sh | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..0e0e2d1 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -192,19 +192,19 @@ test_expect_success 'general options' '
 '
 
 test_expect_success 'general options plus command' '
-   test_completion "git --version check" "checkout " &&
-   test_completion "git --paginate check" "checkout " &&
-   test_completion "git --git-dir=foo check" "checkout " &&
-   test_completion "git --bare check" "checkout " &&
+   test_completion "git --version checkou" "checkout " &&
+   test_completion "git --paginate checkou" "checkout " &&
+   test_completion "git --git-dir=foo checkou" "checkout " &&
+   test_completion "git --bare checkou" "checkout " &&
test_completion "git --help des" "describe " &&
-   test_completion "git --exec-path=foo check" "checkout " &&
-   test_completion "git --html-path check" "checkout " &&
-   test_completion "git --no-pager check" "checkout " &&
-   test_completion "git --work-tree=foo check" "checkout " &&
-   test_completion "git --namespace=foo check" "checkout " &&
-   test_completion "git --paginate check" "checkout " &&
-   test_completion "git --info-path check" "checkout " &&
-   test_completion "git --no-replace-objects check" "checkout "
+   test_completion "git --exec-path=foo checkou" "checkout " &&
+   test_completion "git --html-path checkou" "checkout " &&
+   test_completion "git --no-pager checkou" "checkout " &&
+   test_completion "git --work-tree=foo checkou" "checkout " &&
+   test_completion "git --namespace=foo checkou" "checkout " &&
+   test_completion "git --paginate checkou" "checkout " &&
+   test_completion "git --info-path checkou" "checkout " &&
+   test_completion "git --no-replace-objects checkou" "checkout "
 '
 
 test_expect_success 'setup for ref completion' '
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] oneway_merge(): only lstat() when told to update worktree

[Martin von Zweigbergk]

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
real0m0.288s0m0.233s
user0m0.190s0m0.150s
sys 0m0.090s0m0.080s
---

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))
-- 
1.8.0.1.240.ge8a1f5a

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Dec 2012, #05; Tue, 18)

[Junio C Hamano]

Jeff King  writes:

> On Tue, Dec 18, 2012 at 12:31:43PM -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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/7] make test output coloring more intuitive

[Adam Spiers]

On Thu, Dec 20, 2012 at 4:11 PM, Jeff King  wrote:
> On Thu, Dec 20, 2012 at 03:44:53PM +, Adam Spiers wrote:
>> > diff --git a/t/test-lib.sh b/t/test-lib.sh
>> > index 256f1c6..31f59af 100644
>> > --- a/t/test-lib.sh
>> > +++ b/t/test-lib.sh
>> > @@ -227,7 +227,7 @@ then
>> > pass)
>> > tput setaf 2;;# green
>> > info)
>> > -   tput bold; tput setaf 6;; # bold cyan
>> > +   tput setaf 6;; # cyan
>> > *)
>> > test -n "$quiet" && return;;
>> > esac
>> >
>>
>> 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.

I'll do that if Junio is OK with that.

> Or even just said "I like
> this, please squash it into patch 4 (change info messages from
> yellow/brown to bold cyan).

Yes, I'm OK with this way too :)  Of course "bold" would need to be dropped
from the commit message.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Highlight the link target line in Gitweb using CSS

[Matthew Blissett]

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 
---
The background-colour change is the 'main' (tiny) change.

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.

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:


 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: #44;
+   background-color: #ff4;
+}
+
+a.linenr:hover::before, a.linenr:target::before {
+   content: '⚓';
+   position: absolute;
+}
+
 a.rss_logo {
float: right;
padding: 3px 0px;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Python scripts audited for minimum compatible version and checks added.

[Junio C Hamano]

"Eric S. Raymond"  writes:

>> Should the error message say ciabot.py?
>> 
>> -Peff
>
> Gack.  Yes.  Thaty's what I get for cut-and-pasting too quickly.
> The information about xnml.sex is correct, though.
>
> Want me to resubmit, or will you just patch it?

Can handle it myself; thanks for the patch.

> Note by the way that I still think the entire ciabot subtree (which is 
> my code) should just be nuked.  CIA is not coming back, wishful thinking 
> on Ilkotech's web page notwithstanding.

You are probably right, and interested people could send a patch to
resurrect it, if it turns necessary, from our last commit that has
it.  So let's apply this patch, and then remove the subtree soon
after 1.8.1 ships.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Python version auditing followup

[Junio C Hamano]

e...@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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] builtin/clean.c: Fix some sparse warnings

[Ramsay Jones]

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 
---

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: $PATH pollution and t9902-completion.sh

[Junio C Hamano]

Jeff King  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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: "git config -l" should not expose sensitive information

[Junio C Hamano]

Jeff King  writes:

> 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.

True.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: "git config -l" should not expose sensitive information

[Junio C Hamano]

Michael Haggerty  writes:

> I think the problem is yet another step earlier: why do we build tools
> that encourage people to store passwords in plaintext in a configuration
> file that is by default world-readable?

True.  This particular one mentioned in the thread predates
credential helpers, so it is not faire to say "encourage".
We didn't and we don't.

Care to do a patch to deprecate sendemail.smtppass (i.e. give
warnings to users when it is used) and perhaps replace it with
something based on the credential store or something?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Q: do people compile with NO_FNMATCH on OpenBSD 5.2?

[Greg Troxel]

  [mkstemp truncating output on error]

  diff --git c/wrapper.c w/wrapper.c
  index 68739aa..a066e2e 100644
  --- c/wrapper.c
  +++ w/wrapper.c
  @@ -229,7 +229,7 @@ int xmkstemp(char *template)
  int saved_errno = errno;
  const char *nonrelative_template;

  - if (!template[0])
  + if (strlen(template) != strlen(origtemplate))
  template = origtemplate;

  nonrelative_template = absolute_path(template);

Thanks for the quick fix.

I applied this patch to 1.8.0.1, and then the tests get all the way to
t1402 (separate msg when I figure out why).



pgpaC2CMgoYXA.pgp
Description: PGP signature

Re: [PATCH v6 0/7] make test output coloring more intuitive

[Junio C Hamano]

Jeff King  writes:

>> Good point, I forgot to check what it looked like with -v.  Since this
>> series is already on v6, is there a more lightweight way of addressing
>> this tiny tweak than sending v7?
>
> It is ultimately up to Junio, but I suspect he would be OK if you just
> reposted patch 4/7 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/7] make test output coloring more intuitive

[Jeff King]

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: $PATH pollution and t9902-completion.sh

[Junio C Hamano]

Junio C Hamano  writes:

> Jeff King  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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Dec 2012, #05; Tue, 18)

[Jeff King]

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 -*/
 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: $PATH pollution and t9902-completion.sh

[Jeff King]

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] oneway_merge(): only lstat() when told to update worktree

[Junio C Hamano]

Martin von Zweigbergk  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
> real0m0.288s0m0.233s
> user0m0.190s0m0.150s
> sys 0m0.090s0m0.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))
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Dec 2012, #05; Tue, 18)

[Junio C Hamano]

Jeff King  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)".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: $PATH pollution and t9902-completion.sh

[Torsten Bögershausen]

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 actual.sorted &&
+   >empty &&
+   comm -23 expected.sorted actual.sorted >actual &&
+   test_cmp empty actual &&
+   rm empty actual
 }
 
 # Test __gitcomp.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Highlight the link target line in Gitweb using CSS

[Junio C Hamano]

[jc: adding area expert to Cc]

Matthew Blissett  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 
> ---
> 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:
> 
>
>  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: #44;
> + background-color: #ff4;
> +}
> +
> +a.linenr:hover::before, a.linenr:target::before {
> + content: '⚓';
> + position: absolute;
> +}
> +
>  a.rss_logo {
>   float: right;
>   padding: 3px 0px;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: $PATH pollution and t9902-completion.sh

[Junio C Hamano]

Torsten Bögershausen  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 actual.sorted &&
> + >empty &&
> + comm -23 expected.sorted actual.sorted >actual &&
> + test_cmp empty actual &&
> + rm empty actual
>  }
>  
>  # Test __gitcomp.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] oneway_merge(): only lstat() when told to update worktree

[Martin von Zweigbergk]

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
real0m0.288s0m0.233s
user0m0.190s0m0.150s
sys 0m0.090s0m0.080s

Signed-off-by: Martin von Zweigbergk 
---
 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: $PATH pollution and t9902-completion.sh

[Jeff King]

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 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/^/  /' &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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Python version auditing followup

[Joachim Schmitz]

Junio C Hamano wrote:

e...@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 



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Python version auditing followup

[Junio C Hamano]

"Joachim Schmitz"  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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Change in cvsps maintainership, abd a --fast-export option

[Eric S. Raymond]

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.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
-- Lazarus Long 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: "git config -l" should not expose sensitive information

[Andrew Ardill]

On 21 December 2012 02:49, Aaron Schrab  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  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Highlight the link target line in Gitweb using CSS

[Matthew Blissett]

On 20 December 2012 20:54, Junio C Hamano  wrote:
> [jc: adding area expert to Cc]

Thanks.

> Matthew Blissett  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 
> > ---
> > 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: #44;
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/7] make test output coloring more intuitive

[Adam Spiers]

On Thu, Dec 20, 2012 at 7:21 PM, Junio C Hamano  wrote:
> Jeff King  writes:
>>> Good point, I forgot to check what it looked like with -v.  Since this
>>> series is already on v6, is there a more lightweight way of addressing
>>> this tiny tweak than sending v7?
>>
>> It is ultimately up to Junio, 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 

Re: [PATCH] Documentation/git-clean: Document --force --force

[Soren Brinkmann]

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 
> ---
>  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 `...` 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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Noob Question

[awingnut]

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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation/git-update-index: caution about tree objects

[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 
---
 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Noob Question

[Andrew Ardill]

Hi!

On 21 December 2012 12:07, awingnut  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/git-update-index: caution about tree objects

[Junio C Hamano]

Greg Troxel  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 
> ---
>  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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/git-clean: Document --force --force

[Junio C Hamano]

Soren Brinkmann  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 
>> ---
>>  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 `...` 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 majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 0/7] coloring test output after traffic signal

[Junio C Hamano]

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/t-basic.sh | 214 ++-
 t/test-lib.sh|  29 +---
 2 files changed, 184 insertions(+), 59 deletions(-)

-- 
1.8.1.rc2.225.g8d36ab4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 1/7] tests: test number comes first in 'not ok $count - $message'

[Junio C Hamano]

From: Adam Spiers 

The old output to say "not ok - 1 messsage" was working by accident
only because the test numbers are optional in TAP.

Signed-off-by: Adam Spiers 
Signed-off-by: Junio C Hamano 
---
 t/t-basic.sh | 4 ++--
 t/test-lib.sh| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/t/t-basic.sh b/t/t-basic.sh
index ae6a3f0..c6b42de 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -167,13 +167,13 @@ test_expect_success 'tests clean up even on failures' "
! test -s err &&
! test -f \"trash directory.failing-cleanup/clean-after-failure\" &&
sed -e 's/Z$//' -e 's/^> //' >expect <<-\\EOF &&
-   > not ok - 1 tests clean up even after a failure
+   > not ok 1 - tests clean up even after a failure
> # Z
> # touch clean-after-failure &&
> # test_when_finished rm clean-after-failure &&
> # (exit 1)
> # Z
-   > not ok - 2 failure to clean up causes the test to fail
+   > not ok 2 - failure to clean up causes the test to fail
> # Z
> # test_when_finished \"(exit 2)\"
> # Z
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f8e3733..03b86b8 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -268,7 +268,7 @@ test_ok_ () {
 
 test_failure_ () {
test_failure=$(($test_failure + 1))
-   say_color error "not ok - $test_count $1"
+   say_color error "not ok $test_count - $1"
shift
echo "$@" | sed -e 's/^/#   /'
test "$immediate" = "" || { GIT_EXIT_OK=t; exit 1; }
-- 
1.8.1.rc2.225.g8d36ab4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 2/7] tests: paint known breakages in yellow

[Junio C Hamano]

From: Adam Spiers 

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.

Likewise, change the color of the summarized total number of known
breakages from bold red to the same yellow to be less alarmist and
more consistent with the above.

An earlier version of this patch used bold yellow but because these
are all long-known failures, reminding them to developers in bold
over and over does not help encouraging them to take a look at them
very much.  This iteration paints them in plain yellow instead to
make them less distracting.

Signed-off-by: Adam Spiers 
Signed-off-by: Junio C Hamano 
---
 t/test-lib.sh | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 03b86b8..72aafd0 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -183,6 +183,8 @@ then
tput bold; tput setaf 1;; # bold red
skip)
tput bold; tput setaf 2;; # bold green
+   warn)
+   tput setaf 3;; # brown/yellow
pass)
tput setaf 2;;# green
info)
@@ -281,7 +283,7 @@ test_known_broken_ok_ () {
 
 test_known_broken_failure_ () {
test_broken=$(($test_broken+1))
-   say_color skip "not ok $test_count - $@ # TODO known breakage"
+   say_color warn "not ok $test_count - $@ # TODO known breakage"
 }
 
 test_debug () {
@@ -375,7 +377,7 @@ test_done () {
fi
if test "$test_broken" != 0
then
-   say_color error "# still have $test_broken known breakage(s)"
+   say_color warn "# still have $test_broken known breakage(s)"
msg="remaining $(($test_count-$test_broken)) test(s)"
else
msg="$test_count test(s)"
-- 
1.8.1.rc2.225.g8d36ab4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 3/7] tests: paint skipped tests in blue

[Junio C Hamano]

From: Adam Spiers 

Skipped tests indicate incomplete test coverage.  Whilst this is not a
test failure or other error, it's still not a complete success.

Other testsuite related software like automake, autotest and prove
seem to use blue for skipped tests, so let's follow suit.

Signed-off-by: Adam Spiers 
Signed-off-by: Junio C Hamano 
---
 t/test-lib.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 72aafd0..f32df80 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -182,7 +182,7 @@ then
error)
tput bold; tput setaf 1;; # bold red
skip)
-   tput bold; tput setaf 2;; # bold green
+   tput setaf 4;; # blue
warn)
tput setaf 3;; # brown/yellow
pass)
-- 
1.8.1.rc2.225.g8d36ab4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 4/7] tests: change info messages from yellow/brown to cyan

[Junio C Hamano]

From: Adam Spiers 

Now that we've adopted a "traffic lights" coloring scheme, yellow is
used for warning messages, so we need to re-color info messages to
something less alarmist.  Blue is a universal color for informational
messages; however we are using that for skipped tests in order to
align with the color schemes of other test suites.  Therefore we use
cyan which is also blue-ish, but visually distinct from blue.

This was suggested on the list a while ago and no-one raised any
objections:

http://thread.gmane.org/gmane.comp.version-control.git/205675/focus=205966

An earlier iteration of this patch used bold cyan, but the point of
this change is to make them less alarming; let's drop the boldness.

Also paint the message to report skipping the whole thing via
GIT_SKIP_TESTS mechanism in the same color as the "info" color
that is used on the final summary line for the entire script.

Signed-off-by: Adam Spiers 
Signed-off-by: Junio C Hamano 
---
 t/test-lib.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index f32df80..8b75c9a 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -186,9 +186,9 @@ then
warn)
tput setaf 3;; # brown/yellow
pass)
-   tput setaf 2;;# green
+   tput setaf 2;; # green
info)
-   tput setaf 3;;# brown
+   tput setaf 6;; # cyan
*)
test -n "$quiet" && return;;
esac
@@ -584,7 +584,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
-- 
1.8.1.rc2.225.g8d36ab4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 5/7] tests: refactor mechanics of testing in a sub test-lib

[Junio C Hamano]

From: Adam Spiers 

This will allow us to test the test framework more thoroughly
without disrupting the top-level test metrics.

Signed-off-by: Adam Spiers 
Signed-off-by: Junio C Hamano 
---
 t/t-basic.sh | 85 ++--
 1 file changed, 40 insertions(+), 45 deletions(-)

diff --git a/t/t-basic.sh b/t/t-basic.sh
index c6b42de..d0f46e8 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -55,39 +55,53 @@ test_expect_failure 'pretend we have a known breakage' '
false
 '
 
-test_expect_success 'pretend we have fixed a known breakage (run in sub 
test-lib)' "
-   mkdir passing-todo &&
-   (cd passing-todo &&
-   cat >passing-todo.sh <<-EOF &&
-   #!$SHELL_PATH
-
-   test_description='A passing TODO test
-
-   This is run in a sub test-lib so that we do not get incorrect
-   passing metrics
-   '
-
-   # Point to the t/test-lib.sh, which isn't in ../ as usual
-   TEST_DIRECTORY=\"$TEST_DIRECTORY\"
-   . \"\$TEST_DIRECTORY\"/test-lib.sh
+run_sub_test_lib_test () {
+   name="$1" descr="$2" # stdin is the body of the test code
+   mkdir "$name" &&
+   (
+   cd "$name" &&
+   cat >"$name.sh" <<-EOF &&
+   #!$SHELL_PATH
+
+   test_description='$descr (run in sub test-lib)
+
+   This is run in a sub test-lib so that we do not get incorrect
+   passing metrics
+   '
+
+   # Point to the t/test-lib.sh, which isn't in ../ as usual
+   . "\$TEST_DIRECTORY"/test-lib.sh
+   EOF
+   cat >>"$name.sh" &&
+   chmod +x "$name.sh" &&
+   export TEST_DIRECTORY &&
+   ./"$name.sh" >out 2>err
+   )
+}
 
-   test_expect_failure 'pretend we have fixed a known breakage' '
-   :
-   '
+check_sub_test_lib_test () {
+   name="$1" # stdin is the expected output from the test
+   (
+   cd "$name" &&
+   ! test -s err &&
+   sed -e 's/^> //' -e 's/Z$//' >expect &&
+   test_cmp expect out
+   )
+}
 
+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'
test_done
EOF
-   chmod +x passing-todo.sh &&
-   ./passing-todo.sh >out 2>err &&
-   ! test -s err &&
-   sed -e 's/^> //' >expect <<-\\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)
> 1..1
EOF
-   test_cmp expect out)
 "
+
 test_set_prereq HAVEIT
 haveit=no
 test_expect_success HAVEIT 'test runs if prerequisite is satisfied' '
@@ -137,19 +151,8 @@ then
 fi
 
 test_expect_success 'tests clean up even on failures' "
-   mkdir failing-cleanup &&
-   (
-   cd failing-cleanup &&
-
-   cat >failing-cleanup.sh <<-EOF &&
-   #!$SHELL_PATH
-
-   test_description='Failing tests with cleanup commands'
-
-   # Point to the t/test-lib.sh, which isn't in ../ as usual
-   TEST_DIRECTORY=\"$TEST_DIRECTORY\"
-   . \"\$TEST_DIRECTORY\"/test-lib.sh
-
+   test_must_fail run_sub_test_lib_test \
+   failing-cleanup 'Failing tests with cleanup commands' <<-\\EOF 
&&
test_expect_success 'tests clean up even after a failure' '
touch clean-after-failure &&
test_when_finished rm clean-after-failure &&
@@ -159,14 +162,8 @@ test_expect_success 'tests clean up even on failures' "
test_when_finished \"(exit 2)\"
'
test_done
-
EOF
-
-   chmod +x failing-cleanup.sh &&
-   test_must_fail ./failing-cleanup.sh >out 2>err &&
-   ! test -s err &&
-   ! test -f \"trash directory.failing-cleanup/clean-after-failure\" &&
-   sed -e 's/Z$//' -e 's/^> //' >expect <<-\\EOF &&
+   check_sub_test_lib_test failing-cleanup <<-\\EOF
> not ok 1 - tests clean up even after a failure
> # Z
> # touch clean-after-failure &&
@@ -180,8 +177,6 @@ test_expect_success 'tests clean up even on failures' "
> # failed 2 among 2 test(s)
> 1..2
EOF
-   test_cmp expect out
-   )
 "
 
 
-- 
1.8.1.rc2.225.g8d36ab4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 6/7] tests: test the test framework more thoroughly

[Junio C Hamano]

From: Adam Spiers 

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 
Signed-off-by: Junio C Hamano 
---
 t/t-basic.sh | 105 +++
 1 file changed, 105 insertions(+)

diff --git a/t/t-basic.sh b/t/t-basic.sh
index d0f46e8..384b0ae 100755
--- a/t/t-basic.sh
+++ b/t/t-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 i

[PATCH v7 7/7] tests: paint unexpectedly fixed known breakages in bold red

[Junio C Hamano]

From: Adam Spiers 

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 
Signed-off-by: Junio C Hamano 
---
 t/t-basic.sh | 30 --
 t/test-lib.sh| 13 +
 2 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/t/t-basic.sh b/t/t-basic.sh
index 384b0ae..8973d2c 100755
--- a/t/t-basic.sh
+++ b/t/t-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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Python scripts audited for minimum compatible version and checks added.

[Junio C Hamano]

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 < 0x0204:
 # The limiter is the subprocess module
 sys.stderr.write("git_remote_helpers: requires Python 2.4 or later.")
-- 
1.8.1.rc2.225.g0e05fff

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thomas Sabo Deutschland

[Jorence]

Die Sammlung von  Thomas Sabo Deutschland
   für den Herbst-Winter 2009 ist
eine Wut unter den Liebhabern von Sterling Silber. Dieser Bereich hat seine
Inspiration bilden die beliebte ikonische Puppe namens Barbie. Es war im
Jahr 2009, dass Barbie das Alter von 50 erreicht. Viele Reize für den Winter
wurden speziell von der Firma Barbie zum 50. Geburtstag zu gedenken
eingeführt. Die Sammlung umfasst schönes Armband Designs und Halskette
Entwürfe, die exklusiv sind. Die Kollektion bietet etwas für alle mit
unterschiedlichen Modegeschmack. Dies ist unabhängig von der Tatsache, dass
jemand für klassische diejenigen, Gotik, bescheiden Designs, etc. jagen
Thomas Sabo Anhänger    Verpackung
ist in einer einzigartigen Art und Weise, ihre Entwürfe ergänzt getan.
Einige Pakete enthalten eine kleine quadratische Box, andere Lederbeutel und
als für den Rest, polnisch Kleidung. Die Verpackung selbst ist zu sagen, was
genug ist, um von der Innenseite zu erwarten. Thomas Sabo Verpackung ist für
alle Kunden, Klienten und Kunden durchgeführt. Ob Sie kaufen nur ein Element
oder im Großhandel sind die Leistungen die gleichen. Das Unternehmen bietet
eine breite Vielfalt von Schmuck-einige sind aus purem Gold und andere aus
Silber mit anderen Edelmetallen geschmückt gemacht.  Thomas Sabo Charms
   und Amulette haben Hunderte von
einzigartigen, frechen und stilvollen Schmuck für Männer und Frauen. Hier
finden Sie weitere Sammlungen von Uhren, Ohrringe und Halsketten, die
garantiert auf Ihre speziellen Bedürfnisse zugeschnitten sind. Aus jedem
Geschäft, haben Sie eine große Auswahl an Auswahl Ihrer Sabo Charme und
Armbänder aus Silikon, Stahl, Leder oder Keramik.
Thomas Sabo Schmuck    in vielen
verschiedenen Stilen und Designs auch so wird, viele unterschiedliche
Interessen ansprechen. Das Sortiment umfasst Reize, die Tiere, Briefe,
Leben, Spaß, Liebe, Glück, Natur, Anhänger, Religion, besondere Anlässe,
Kinder, Kleidung, Glamour, birthstones, Perlen und Anhänger vertreten. Die
große Sache über diese Reize ist, dass sie verwendet werden, um etwas, das
für Sie von Bedeutung ist, zu zeigen; sie Meilensteine, Lieben, Hobbys,
Interessen und Dinge, die euch nahe sind vertreten  Thomas Sabo Online Shop
  .



-
Thomas Sabo Deutschland 
Thomas Sabo Anhänger 
Thomas Sabo Charms 
Thomas Sabo Schmuck 
Thomas Sabo Online Shop 
--
View this message in context: 
http://git.661346.n2.nabble.com/Thomas-Sabo-Deutschland-tp7573480.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder

[David Aguilar]

Use $TMPDIR when creating the /dev/null placeholder for p4merge.
This keeps it out of the current directory.

Reported-by: Jeremy Morton 
Signed-off-by: David Aguilar 
---
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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Python version auditing followup

[Joachim Schmitz]

> From: Junio C Hamano [mailto:gits...@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"  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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html