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 gits...@pobox.com wrote:
 David Aguilar dav...@gmail.com writes:

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

 Reported-by: Jeremy Morton ad...@game-point.net
 Signed-off-by: David Aguilar dav...@gmail.com
 ---
 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 dav...@gmail.com writes:


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

Reported-by: Jeremy Morton ad...@game-point.net
Signed-off-by: David Aguilar dav...@gmail.com
---
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 gits...@pobox.com 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 pclo...@gmail.com 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 s...@iti.es   http://www.iti.es/
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 e...@thyrsus.com
---
 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], 'zipfile...'
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



-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

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
More 

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

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 p...@peff.net:
 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.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a
--
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 p...@peff.net 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 gits...@pobox.com wrote:
  Adam Spiers g...@adamspiers.org 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 p...@peff.net 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 gits...@pobox.com wrote:
  Adam Spiers g...@adamspiers.org 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 p...@peff.net 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 p...@peff.net 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 p...@peff.net 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 dav...@gmail.com 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 21 || 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 p...@peff.net 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 tbo...@web.de
---
 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

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

[Junio C Hamano]

Jeff King p...@peff.net 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 p...@peff.net 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 m...@blissett.me.uk
---
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:
http://en.wikipedia.org/wiki/Git_(software)#cite_note-1

 gitweb/static/gitweb.css |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
index cb86d2d..9f54311 100644
--- a/gitweb/static/gitweb.css
+++ b/gitweb/static/gitweb.css
@@ -546,6 +546,16 @@ a.linenr {
text-decoration: none
 }
 
+a.linenr:hover, a.linenr:target {
+   color: #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 e...@thyrsus.com 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 ram...@ramsay1.demon.co.uk
---

Hi Zoltan,

If you have already updated your patch and made this redundant
(it's been a few days since I read the list or fetched git.git),
please ignore this. Otherwise, could you please squash this into
the new version of commit 16e4033e6 (git-clean: Display more
accurate delete messages, 17-12-2012).

[BTW, in the same conditional expression you have an strncmp()
call which doesn't quite follow the style/conventions of the
existing code.]

Thanks!

ATB,
Ramsay Jones

 builtin/clean.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 1c25a75..0c603c8 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -38,13 +38,13 @@ static void print_filtered(const char *msg, struct 
string_list *lst)
 {
int i;
char *name;
-   char *dir = 0;
+   char *dir = NULL;
 
sort_string_list(lst);
 
for (i = 0; i  lst-nr; i++) {
name = lst-items[i].string;
-   if (dir == 0 || strncmp(name, dir, strlen(dir)) != 0)
+   if (!dir || strncmp(name, dir, strlen(dir)) != 0)
printf(%s %s\n, msg, name);
if (name[strlen(name) - 1] == '/')
dir = name;
-- 
1.8.0

--
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 p...@peff.net writes:

   2. Loosen the test to look for the presence of checkout, but not
  fail when other items are present. Bonus points if it makes sure
  that everything returned starts with check.

 I think (2) is the ideal solution in terms of behavior, but writing it
 may be more of a pain.

Yeah, I think (2) is the way to go.

--
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 p...@peff.net 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 mhag...@alum.mit.edu 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 p...@peff.net writes:

 Good point, I forgot to check what it looked like with -v.  Since this
 series is already on v6, is there a more lightweight way of addressing
 this tiny tweak than sending v7?

 It is ultimately up to Junio, but I suspect he would be OK if you just
 reposted patch 4/7 with the above squashed. Or even just said I like
 this, please squash it into patch 4 (change info messages from
 yellow/brown to bold cyan).

Surely; as long as the series is not in 'next', the change to be
squashed is not too big and it is not too much work (and in this
case it certainly is not).

I actually wonder if skipped test in bold blue and known breakage
in bold yellow should also lose the boldness.  Errors and warnings
in bold are good, but I would say the degree of need for attention
are more like this:

error (failed tests - you should look into it)
skip (skipped - perhaps you need more packages?)
warn (expected failure - you may want to look into fixing it someday)
info
pass

The expected_failure cases painted in warn are all long-known
failures; I do not think reminding about them in bold over and
over will help encouraging the developers take a look at them.

The skipped cases fall into two categories.  Either you already
know you choose to not to care (e.g. I do not expect to use git-p4
and decided not to install p4 anywhere, so I may have t98?? on
GIT_SKIP_TESTS environment) or you haven't reached that point on a
new system and haven't realized that you didn't install a package
needed to run tests you care about (e.g. cvsserver tests would not
run without Perl interface to SQLite).  For the former, the bold
output is merely distracting; for the latter, bold _might_ help in
this case.

At least, I think

GIT_SKIP_TESTS=t98?? sh t9800-git-p4-basic.sh -v

should paint skipping test t9800 altogether (emitted with -v) and
the last line 1..0 # SKIP skip all tests in t9800 both in the same
info color.

How about going further to reduce bold a bit more, like this?

diff --git a/t/test-lib.sh b/t/test-lib.sh
index aaf013e..2bbb81d 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -182,13 +182,13 @@ then
error)
tput bold; tput setaf 1;; # bold red
skip)
-   tput bold; tput setaf 4;; # bold blue
+   tput setaf 4;; # bold blue
warn)
-   tput bold; tput setaf 3;; # bold brown/yellow
+   tput setaf 3;; # bold brown/yellow
pass)
tput setaf 2;;# green
info)
-   tput bold; tput setaf 6;; # bold cyan
+   tput setaf 6;; # bold cyan
*)
test -n $quiet  return;;
esac
@@ -589,7 +589,7 @@ for skp in $GIT_SKIP_TESTS
 do
case $this_test in
$skp)
-   say_color skip 3 skipping test $this_test altogether
+   say_color info 3 skipping test $this_test altogether
skip_all=skip all tests in $this_test
test_done
esac
--
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 gits...@pobox.com writes:

 Jeff King p...@peff.net writes:

   2. Loosen the test to look for the presence of checkout, but not
  fail when other items are present. Bonus points if it makes sure
  that everything returned starts with check.

 I think (2) is the ideal solution in terms of behavior, but writing it
 may be more of a pain.

 Yeah, I think (2) is the way to go.

The beginning of such a change may look like the attached patch.

If we want to go for the bonus points, we would either add another
parameter prefix to the test_completion function, or introduce the
test_complete_command function that takes that prefix parameter, and
in addition to making sure lines from expect is fully contained in
the actual, make sure that output from

comm -13 expect.sorted actual.sorted

all begin with that prefix string, perhaps with

grep -v ^$prefix

or something.  The test_fully_contains function needs to be renamed
if somebody goes that additional step.

diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..5fab389 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -54,10 +54,16 @@ run_completion ()
__git_wrap__git_main  print_comp
 }
 
+test_fully_contains () {
+   sort $1 expect.sorted 
+   sort $2 actual.sorted 
+   test $(comm -23 expect.sorted actual.sorted | wc -l) = 0
+}
+
 # Test high-level completion
 # Arguments are:
 # 1: typed text so far (cur)
-# 2: expected completion
+# 2: expected completion (if missing, this is read from stdin)
 test_completion ()
 {
if test $# -gt 1
@@ -67,7 +73,7 @@ test_completion ()
sed -e 's/Z$//' expected
fi 
run_completion $1 
-   test_cmp expected out
+   test_fully_contains expected out
 }
 
 # Test __gitcomp.
--
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 martinv...@gmail.com writes:

 Although the subject line of 613f027 (read-tree -u one-way merge fix
 to check out locally modified paths., 2006-05-15) mentions read-tree
 -u, it did not seem to check whether -u was in effect. Not checking
 whether -u is in effect makes e.g. read-tree --reset lstat() the
 worktree, even though the worktree stat should not matter for that
 operation.

 This speeds up e.g. git reset a little on the linux-2.6 repo (best
 of five, warm cache):

 Before  After
 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 p...@peff.net writes:

 So our attempt for more compile-time safety may actually introduce a
 run-time bug.  And it is a hard bug to find, as the preprocessor
 magically converts the error code into -1 without you being able to
 see it in the code.

 It would be safer to just unconditionally use the macros and drop the
 return values from the functions entirely, like the patch below
 (squashed on top of what is in jk/error-const-return). But it cannot
 work for error(), because the variadic nature means we need to restrict
 ourselves to __GNUC__.

While I like the general direction, I am not sure if we are OK with
the introduction of

  #undef config_error_nonbool
 -int config_error_nonbool(const char *var)
 +void config_error_nonbool(const char *var)
  {
 - return error(Missing value for '%s', var);
 + error(Missing value for '%s', var);
  }

a new, arguably false, returned value not used warning from this
point.  Perhaps it is fine for now, as we have tons of calls that do
not cast the return value to (void).
--
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 out 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 m...@blissett.me.uk writes:

 This is useful when a Gitweb link with a target (like #l100) refers to
 a line in the last screenful of text.  Highlight the background in
 yellow, and display a ⚓ character on the left.  Show the same
 highlight when hovering the mouse over a line number.

 Signed-off-by: Matthew Blissett m...@blissett.me.uk
 ---
 The background-colour change is the 'main' (tiny) change.

In the blob view, I think it does make it more discoverable that
these line numbers are links, so I personally think a.linenr:hover
part is an improvement.  I am not sure about other three changes
adding any value, though.

 Consider the ::before part a suggestion.  I think it helps show the
 target line, but it does overlap the first character of any line 999.

Actually, when viewing the blame view, this is even worse, as it
seems to always overlap.  The background color ought to be enough
cue without being overly distracting, I would have to say.

Jakub?  Comments on any other points I may have missed?


 I've tested this on the browsers I have access to, which excludes
 Internet Explorer.  Since it's cosmetic it shouldn't matter if it doesn't
 work.

 Wikipedia use similar CSS for their citation links:
 http://en.wikipedia.org/wiki/Git_(software)#cite_note-1

  gitweb/static/gitweb.css |   10 ++
  1 file changed, 10 insertions(+)

 diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
 index cb86d2d..9f54311 100644
 --- a/gitweb/static/gitweb.css
 +++ b/gitweb/static/gitweb.css
 @@ -546,6 +546,16 @@ a.linenr {
   text-decoration: none
  }
  
 +a.linenr:hover, a.linenr:target {
 + color: #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 tbo...@web.de writes:

 On 20.12.12 21:01, Jeff King wrote:
 +test_fully_contains () {
 +   sort $1 expect.sorted 
 +   sort $2 actual.sorted 
 +   test $(comm -23 expect.sorted actual.sorted | wc -l) = 0
 +}

 (Good to learn about the comm command, thanks )
 What do we think about this:

Three points to consider.

 * Do _all_ tests that use test_completion not care about the actual
   order of choices that come out of the completion machinery?

 * Do _all_ tests that use test_completion not care about having
   extra choice, or is the command name completion the only odd
   case?

 * Is this still as easy to extend as the original to conditionally
   verify that all extra output share the same prefix?

 diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
 index 3cd53f8..82eeba7 100755
 --- a/t/t9902-completion.sh
 +++ b/t/t9902-completion.sh
 @@ -62,12 +62,16 @@ test_completion ()
  {
   if test $# -gt 1
   then
 - printf '%s\n' $2 expected
 + printf '%s\n' $2 | sort expected.sorted
   else
 - sed -e 's/Z$//' expected
 + sed -e 's/Z$//' | sort expected.sorted
   fi 
   run_completion $1 
 - test_cmp expected out
 + sort out actual.sorted 
 + empty 
 + comm -23 expected.sorted actual.sorted actual 
 + test_cmp empty actual 
 + rm empty actual
  }
  
  # Test __gitcomp.
--
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 out actual.sorted 
 + empty 
 + comm -23 expected.sorted actual.sorted actual 
 + test_cmp empty actual 
 + rm empty actual

I like test_* helpers that tell you what happened on error, but this
output will be kind of a weird diff (it is a diff showing things you
expected to have but did not get as additions, and no mention of things
you expected and got).

The output is human readable, so I think it is perfectly OK to print a
message about what is going on (we do this in test_expect_code, for
example). Something like:

  test_fully_contains() {
sort $1 expect.sorted 
sort $2 actual.sorted 
comm -23 expect.sorted actual.sorted missing
test -f missing -a ! -s missing 
rm -f expect.sorted actual.sorted missing 
return 0

{
  echo test_fully_contains: some lines were missing
  echo expected:
  sed 's/^/  /' $1
  echo actual:
  sed 's/^/  /' $2
  echo missing:
  sed 's/^/  /' missing
} 2
return 1
  }

Though come to think of it, just showing the diff between expect.sorted
and actual.sorted would probably be enough. It would show the missing
elements as deletions, the found elements as common lines, and the
extra elements as additions (which are not an error, but when you are
debugging, might be useful to know about).

-Peff
--
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 j...@schmitz-digital.de writes:

 Junio C Hamano wrote:
 I personally would think 2.6 is recent enough.  Which platforms that
 are long-term-maintained by their vendors still pin their Python at
 2.4.X?  2.4.6 was in 2008 that was source only, 2.4.4 was in late
 2006 that was the last 2.4 with binary release.

 Objections?  Comments?

 We have a working 2.4.2 for HP-NonStop and some major problems getting
 2.7.3 to work.

I do not think a platform that stops at 2.4.2 instead of going to
higher 2.4.X series deserves to be called long term maintained by
their vendors.  It sounds more like attempted to supply 2.4.X and
abandoned the users once onee port was done to me.

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

To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
-- Lazarus Long 
--
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 aa...@schrab.com wrote:
 Tools outside of the core git tree may add support for new config keys which
 are meant to contain sensitive information, and there would be no way for
 `git config` to know about those.

I understand that we've come down mostly on the 'users must check
before sending' side of things, but this point isn't necessarily true.

It wouldn't be too hard to create a config setting with a list of
'sensitive' keys filled with sensible defaults. It would be the job of
the 3rd party to add the relevant keys to this config file. This
wouldn't help with old 3rd party tools but would provide a way to
'hide' things automatically. A user could of course configure this
themselves (though one would think most who knew how wouldn't need
to).

On 21 December 2012 02:52, Jeff King p...@peff.net wrote:
 I think that attempting to do this would only result in a false sense
 of security.

 Yeah. Thanks for a dose of sanity. I was really trying not to say the
 given advice is bad, and we cannot help those people. But I think you
 are right; the only sensible path is for the user to inspect the output
 before posting it.

One thing that a new option could provide (or maybe even the existing
option if it detects an interactive session) is to prompt the user to
review the content before outputting it. This is a nice way of helping
users who don't know that there might be sensitive information in the
output. Are there any use cases where prompting the user would be
annoying when using this command?

Regards,

Andrew Ardill
--
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 gits...@pobox.com wrote:
 Jeff King p...@peff.net writes:
 Good point, I forgot to check what it looked like with -v.  Since this
 series is already on v6, is there a more lightweight way of addressing
 this tiny tweak than sending v7?

 It is ultimately up to Junio, but I suspect he would be OK if you just
 reposted patch 4/7 with the above squashed. Or even just said I like
 this, please squash it into patch 4 (change info messages from
 yellow/brown to bold cyan).

 Surely; as long as the series is not in 'next', the change to be
 squashed is not too big and it is not too much work (and in this
 case it certainly is not).

OK.

 I actually wonder if skipped test in bold blue and known breakage
 in bold yellow should also lose the boldness.  Errors and warnings
 in bold are good, but I would say the degree of need for attention
 are more like this:

 error (failed tests - you should look into it)
 skip (skipped - perhaps you need more packages?)
 warn (expected failure - you may want to look into fixing it someday)
 info
 pass

 The expected_failure cases painted in warn are all long-known
 failures; I do not think reminding about them in bold over and
 over will help encouraging the developers take a look at them.

As Peff already noted, on many (most?) X terminals bold colours are
just brighter colours, rather than a heavier typeface.  How bold they
look is therefore dependent on the colour scheme used by that
terminal.

 The skipped cases fall into two categories.  Either you already
 know you choose to not to care (e.g. I do not expect to use git-p4
 and decided not to install p4 anywhere, so I may have t98?? on
 GIT_SKIP_TESTS environment) or you haven't reached that point on a
 new system and haven't realized that you didn't install a package
 needed to run tests you care about (e.g. cvsserver tests would not
 run without Perl interface to SQLite).  For the former, the bold
 output is merely distracting; for the latter, bold _might_ help in
 this case.

Very good point.

 At least, I think

 GIT_SKIP_TESTS=t98?? sh t9800-git-p4-basic.sh -v

 should paint skipping test t9800 altogether (emitted with -v) and
 the last line 1..0 # SKIP skip all tests in t9800 both in the same
 info color.

 How about going further to reduce bold a bit more, like this?

 diff --git a/t/test-lib.sh b/t/test-lib.sh
 index aaf013e..2bbb81d 100644
 --- a/t/test-lib.sh
 +++ b/t/test-lib.sh
 @@ -182,13 +182,13 @@ then
 error)
 tput bold; tput setaf 1;; # bold red
 skip)
 -   tput bold; tput setaf 4;; # bold blue
 +   tput setaf 4;; # bold blue

The comment still says bold.

 warn)
 -   tput bold; tput setaf 3;; # bold brown/yellow
 +   tput setaf 3;; # bold brown/yellow

Ditto here ...

 pass)
 tput setaf 2;;# green
 info)
 -   tput bold; tput setaf 6;; # bold cyan
 +   tput setaf 6;; # bold cyan

... and here.

 *)
 test -n $quiet  return;;
 esac
 @@ -589,7 +589,7 @@ for skp in $GIT_SKIP_TESTS
  do
 case $this_test in
 $skp)
 -   say_color skip 3 skipping test $this_test altogether
 +   say_color info 3 skipping test $this_test altogether
 skip_all=skip all tests in $this_test
 test_done
 esac

Yes, I like this last hunk especially.

I have no objection in principle to a reduction in boldness.

However, I am beginning to get disheartened that at this rate, this
series will never land.  I already submitted v4 of the series which
already had non-bold blue.  I then received feedback indicating that
bold blue would be more suitable, so despite alarm bells beginning to
ring in my head, I submitted v5 with bold blue, declaring that that
would be my last version:

  http://article.gmane.org/gmane.comp.version-control.git/206042

A further concern about info messages not being blue prompted me
to attempt to canvass more opinions:

  http://article.gmane.org/gmane.comp.version-control.git/209321

I received none, so submitted v6 based on my best judgement.  Now we
are talking about a potential v7 going *back* to non-bold blue.  I can
submit v7 if you think it's worth it, but would that really be the end
of the discussion?  It's clear from the above that colour scheme
design by committee is about as good an idea as asking a bunch of kids
to reach consensus on their favourite colour ;-)

So if possible I'd be very happy for Junio to simply make an executive
decision (I don't care which way, as long as it fits the traffic
lights scheme and uses distinct hues of blue/cyan for the different
categories of skip/info messages), tweak the latest v6 series

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 soren.brinkm...@xilinx.com
 ---
  Documentation/git-clean.txt | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
 index 9f42c0d..0b31454 100644
 --- a/Documentation/git-clean.txt
 +++ b/Documentation/git-clean.txt
 @@ -23,6 +23,9 @@ example, be useful to remove all build products.
  If any optional `path...` arguments are given, only those paths
  are affected.
  
 +Nested git repositories are not removed unless the '-f' option is
 +passed to 'git clean' twice.
 +
  OPTIONS
  ---
  -d::
 @@ -35,6 +38,8 @@ OPTIONS
  --force::
   If the git configuration variable clean.requireForce is not set
   to false, 'git clean' will refuse to run unless given -f or -n.
 + Pass this option twice to 'git clean' in order to also remove
 + nested git repositories.
  
  -n::
  --dry-run::
 -- 
 1.8.0.2
 
 
 --
 To unsubscribe from this list: send the line unsubscribe git in
 the body of a message to 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 g...@ir.bbn.com
---
 Documentation/git-update-index.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-update-index.txt 
b/Documentation/git-update-index.txt
index 9d0b151..6ce65fa 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -29,6 +29,11 @@ Modifies the index or directory cache. Each file mentioned 
is updated
 into the index and any 'unmerged' or 'needs updating' state is
 cleared.
 
+Note that update-index does not check that the modifications preserve
+the expected invariants.  In particular, an index normally holds
+regular blobs, executable blobs, symlink blobs, and gitlinks.
+Therefore, adding a tree object is not likely useful.
+
 See also linkgit:git-add[1] for a more user-friendly way to do some of
 the most common operations on the index.
 
@@ -210,7 +215,7 @@ back on 3-way merge.
 
 . mode SP type SP sha1  TAB path
 +
-The second format is to stuff 'git ls-tree' output
+The second format is to stuff 'git ls-tree -r' output
 into the index file.
 
 . mode SP sha1 SP stage TAB path
-- 
1.8.0.1

--
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 wtriker@gmail.com wrote:
 My main questions center around the git repository and accessing it.

The main thing you need to know is that you can work on your code base
in the *exact* same way while using git. You don't *have* to change
anything about how you work, as git's primary purpose is to store
snapshots of your work so that you have a history of what has changed.

That being said, you can (and maybe should) change how you work to
take into account the power of git. Most of what you do will stay the
same, however.

 1) Should I install git on Linux or Windows or does it matter?

Install git wherever you need to access the code. From the sounds of
it you will want git on both machines, as you are working on windows
and but keeping the code on the linux shared drive. When working on
the windows machine you will use a windows copy of git to manipulate
the workspace, though I'm not sure if there are any gotchas with the
interaction with a linux shared drive.

If you want to manipulate the repository from the linux machine you
will need git on it as well.

Unless you're using a git server, manipulating the repository is a
local action and so is performed by the client. That is, when working
on windows use the windows client, if you also work on the linux
machine then you will need a client there as well.

 2) How will my build scripts access the source? Will it be the same as
 now (my scripts 'cd' to the Eclipse project directory and run there) or
 do I need to add a wrapper to my script to check out the entire source
 for the builds?

It's the same as now. Git uses the concept of a 'work tree' to talk
about the actual files you are working on now. The work tree
corresponds exactly to your current project files. When you create a
git repository you gain the ability to store snapshots of this working
tree into the 'object store', as well as metadata about the snapshots,
so that you can restore that snapshot later.

Your actual files keep their current layout and format, until you change them.

 3) How do I move my current Eclipse project into git after I create the
 empty repository? I can only find info on how to import git into Eclipse
 not the other way around.

You have two options. Create the git repository in the same location
as your Eclipse project. Navigate to the project folder using git bash
and do a 'git init' inside it; voila! you now have a git repository.
You can choose to create a 'remote' repository somewhere to store a
backup of your code as well, but this _still_ requires you to init a
local repository to backup.

The other option is to create a blank repository somewhere (anywhere)
and then tell that repository to use your Eclipse project as its
working tree. The benefit to doing this is being able to keep your
snapshots and metadata in a different location to your working
directory (say keep the snapshots on a local windows drive while your
working directory is on the linux share). Unless you shouldn't or
aren't able to create the repository within the Eclipse project, I
would recommend against this.

 4) Do I need to checkout the entire project from Eclipse to modify and
 test it or only the classes I want to change? Does the plugin get the
 others as needed when I run the app within Eclipse for testing?

Not sure exactly what you are asking here, but in general people will
'clone' an entire repository including all its history. If you want to
update only certain files that is fine, but the commit object stores
the state of the entire tree of files. Note that a commit object does
_not_ store the difference between two snapshots, but stores the
entire state of the files. You can grab a file from a given snapshot
and test that along side files from a second snapshot, but if you
wanted to commit the resulting tree to the repository it would store a
third snapshot containing the exact state of all files.

Hopefully that clears it up for you?

Regards,

Andrew Ardill
--
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 g...@ir.bbn.com writes:

 While one can add tree objects to the index, this is not currently
 useful.  Therefore, use git ls-tree -r as the example to be fed to
 --index-info.  Add a section explaining about expected index contents.
 (Thanks to Junio for explaining this to me in August of 2011.)

 Signed-off-by: Greg Troxel g...@ir.bbn.com
 ---
  Documentation/git-update-index.txt | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

 diff --git a/Documentation/git-update-index.txt 
 b/Documentation/git-update-index.txt
 index 9d0b151..6ce65fa 100644
 --- a/Documentation/git-update-index.txt
 +++ b/Documentation/git-update-index.txt
 @@ -29,6 +29,11 @@ Modifies the index or directory cache. Each file mentioned 
 is updated
  into the index and any 'unmerged' or 'needs updating' state is
  cleared.
  
 +Note that update-index does not check that the modifications preserve
 +the expected invariants.  In particular, an index normally holds
 +regular blobs, executable blobs, symlink blobs, and gitlinks.
 +Therefore, adding a tree object is not likely useful.
 +

I find this unnecessarily alarmist as a description meant for
general audiences.  For the normal mode of operations of the command
(e.g. git update-index --add --remove hello.c), whatever you mean
by expected invariants are fully preserved.

I think you meant this for --cacheinfo and --index-info options,
which are primarily meant for people who know what they are doing
(that includes the use of this command in scripted Porceains) or Git
developers who want to work on enhancing the index (and to them,
being able to record anything is more convenient).

 @@ -210,7 +215,7 @@ back on 3-way merge.
  
  . mode SP type SP sha1  TAB path
  +
 -The second format is to stuff 'git ls-tree' output
 +The second format is to stuff 'git ls-tree -r' output
  into the index file.

This hunk is good.

Thanks.
--
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 soren.brinkm...@xilinx.com writes:

 Ping?

I *think* it is a mistake for the command to remove a separate
project repository within, with any number of -f, so I'd rather
see a patch to fix it, instead of casting such a misbehaviour as a
feature in stone by documenting it.

I dunno.

 On Thu, Dec 13, 2012 at 05:46:55PM -0800, Soren Brinkmann wrote:
 This patch documents the behavior of 'git clean' when
 encountering nested git repositories.
 Such repositories are only deleted if '-f' is passed twice
 to 'git clean'.
 
 Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
 ---
  Documentation/git-clean.txt | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
 index 9f42c0d..0b31454 100644
 --- a/Documentation/git-clean.txt
 +++ b/Documentation/git-clean.txt
 @@ -23,6 +23,9 @@ example, be useful to remove all build products.
  If any optional `path...` arguments are given, only those paths
  are affected.
  
 +Nested git repositories are not removed unless the '-f' option is
 +passed to 'git clean' twice.
 +
  OPTIONS
  ---
  -d::
 @@ -35,6 +38,8 @@ OPTIONS
  --force::
  If the git configuration variable clean.requireForce is not set
  to false, 'git clean' will refuse to run unless given -f or -n.
 +Pass this option twice to 'git clean' in order to also remove
 +nested git repositories.
  
  -n::
  --dry-run::
 -- 
 1.8.0.2
 
 
 --
 To unsubscribe from this list: send the line unsubscribe git in
 the body of a message to 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 g...@adamspiers.org

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 g...@adamspiers.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 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 g...@adamspiers.org

Yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where
green conveys the impression that everything's OK, and amber that
something's not quite right.

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 g...@adamspiers.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 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 g...@adamspiers.org

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 g...@adamspiers.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 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 g...@adamspiers.org

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 g...@adamspiers.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 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 g...@adamspiers.org

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

Signed-off-by: Adam Spiers g...@adamspiers.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 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 2err
+   )
+}
 
-   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 2err 
-   ! 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 2err 
-   ! 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 g...@adamspiers.org

Add 5 new full test suite runs each with a different number of
passing/failing/broken/fixed tests, in order to ensure that the
correct exit code and output are generated in each case.  As before,
these are run in a subdirectory to avoid disrupting the metrics for
the parent tests.

Signed-off-by: Adam Spiers g...@adamspiers.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 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 is satisfied' '
-- 

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

[Junio C Hamano]

From: Adam Spiers g...@adamspiers.org

Change color of unexpectedly fixed known breakages to bold red.  An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing.  Either way this is
an error which is potentially as bad as a failing test, and as such is
no longer portrayed as a pass in the output.

Signed-off-by: Adam Spiers g...@adamspiers.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 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
http://www.thomassaboschmuckkaufen.eu/   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 http://www.thomassaboschmuckkaufen.eu/   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
http://www.thomassaboschmuckkaufen.eu/   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 http://www.thomassaboschmuckkaufen.eu/   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
http://www.thomassaboschmuckkaufen.eu/  .



-
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 ad...@game-point.net
Signed-off-by: David Aguilar dav...@gmail.com
---
No mktemp usage in this round.

 mergetools/p4merge | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/mergetools/p4merge b/mergetools/p4merge
index 295361a..52f7c8f 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -1,29 +1,21 @@
 diff_cmd () {
+   empty_file=
+
# p4merge does not like /dev/null
-   rm_local=
-   rm_remote=
if test /dev/null = $LOCAL
then
-   LOCAL=./p4merge-dev-null.LOCAL.$$
-   $LOCAL
-   rm_local=true
+   LOCAL=$(create_empty_file)
fi
if test /dev/null = $REMOTE
then
-   REMOTE=./p4merge-dev-null.REMOTE.$$
-   $REMOTE
-   rm_remote=true
+   REMOTE=$(create_empty_file)
fi
 
$merge_tool_path $LOCAL $REMOTE
 
-   if test -n $rm_local
-   then
-   rm -f $LOCAL
-   fi
-   if test -n $rm_remote
+   if test -n $empty_file
then
-   rm -f $REMOTE
+   rm -f $empty_file
fi
 }
 
@@ -33,3 +25,10 @@ merge_cmd () {
$merge_tool_path $BASE $LOCAL $REMOTE $MERGED
check_unchanged
 }
+
+create_empty_file () {
+   empty_file=${TMPDIR:-/tmp}/git-difftool-p4merge-empty-file.$$
+   $empty_file
+
+   printf $empty_file
+}
-- 
1.8.1.rc2.6.g18499ba

--
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 j...@schmitz-digital.de writes:
 
  Junio C Hamano wrote:
  I personally would think 2.6 is recent enough.  Which platforms that
  are long-term-maintained by their vendors still pin their Python at
  2.4.X?  2.4.6 was in 2008 that was source only, 2.4.4 was in late
  2006 that was the last 2.4 with binary release.
 
  Objections?  Comments?
 
  We have a working 2.4.2 for HP-NonStop and some major problems getting
  2.7.3 to work.
 
 I do not think a platform that stops at 2.4.2 instead of going to
 higher 2.4.X series deserves to be called long term maintained by
 their vendors.  It sounds more like attempted to supply 2.4.X and
 abandoned the users once one port was done to me.

Well, not entirely wrong, but not all true at too.
I guess I need to defend the vendor here: It is not really the Vendor (HP) that 
provided Python 2.4.2 or tries to provide 2.7.3, it
is a volunteer and community effort. HP did sponsor the 2.4.2 port though (by 
allowing an HP employee to do the port inn his regular
working hours). It is not doing this any longer (since 2007). Since then it is 
a small group doing this on a purely voluntary basis
in their spare time (one HP employee amongst them, me).
Same goes for the git port BTW. And for every other port provided on 
http://ituglib.connect-cummunity.org (this machine is sponsored
by HP).
Almost every other port, as some pretty recently made it into the officially 
supported O/S version, so far: Samba, bash, coreutils,
vim, gzip, bzip2, Perl, PHP.

Bye, Jojo

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