contrib: remove git-p4import

The git p4import documentation has suggested git p4 as a better
alternative for more than 6 years.  (According to the mailing list
discussion when it was moved to contrib/, git-p4import has serious
bugs --- e.g., its incremental mode just doesn't work.) Since then,
git p4 has been actively developed and was promoted to a standard git
command alongside git svn.

Searches on google.com/trends and stackoverflow suggest that no one is
looking for git-p4import any more.  Remove it.

Noticed while considering marking the contrib/p4import/git-p4import.py
script executable as part of a wider sweep.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test: make FILEMODE a lazy prereq

This way, test authors don't need to remember to source
lib-prereq-FILEMODE.sh before using the FILEMODE prereq to guard tests
that rely on the executable bit being honored when checking out files.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test: replace shebangs with descriptions in shell libraries

A #! line in these files is misleading, since these scriptlets are
meant to be sourced with '.' (using whatever shell sources them)
instead of run directly using the interpreter named on the #! line.

Removing the #! line shouldn't hurt syntax highlighting since
these files have filenames ending with '.sh'.  For documentation,
add a brief description of how the files are meant to be used in
place of the shebang line.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remove #!interpreter line from shell libraries

In a shell snippet meant to be sourced by other shell scripts, an
opening #! line does more harm than good.

The harm:

 - When the shell library is sourced, the interpreter and options from
   the #! line are not used.  Specifying a particular shell can
   confuse the reader into thinking it is safe for the shell library
   to rely on idiosyncrasies of that shell.

 - Using #! instead of a plain comment drops a helpful visual clue
   that this is a shell library and not a self-contained script.

 - Tools such as lintian can use a #! line to tell when an
   installation script has failed by forgetting to set a script
   executable.  This check does not work if shell libraries also start
   with a #! line.

The good:

 - Text editors notice the #! line and use it for syntax highlighting
   if you try to edit the installed scripts (without ".sh" suffix) in
   place.

The use of the #! for file type detection is not needed because Git's
shell libraries are meant to be edited in source form (with ".sh"
suffix).  Replace the opening #! lines with comments.

This involves tweaking the test harness's valgrind support to find
shell libraries by looking for "# " in the first line instead of "#!"
(see v1.7.6-rc3~7, 2011-06-17).

Suggested by Russ Allbery through lintian.  Thanks to Jeff King and
Clemens Buchacher for further analysis.

Tested by searching for non-executable scripts with #! line:

	find . -name .git -prune -o -type f -not -executable |
	while read file
	do
		read line <"$file"
		case $line in
		'#!'*)
			echo "$file"
			;;
		esac
	done

The only remaining scripts found are templates for shell scripts
(unimplemented.sh, wrap-for-bin.sh) and sample input used in tests
(t/t4034/perl/{pre,post}).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge commit '688eb87c9444686180d8f379ab854bcbc34db4db' into jn/scripts-updates

* commit '688eb87c9444686180d8f379ab854bcbc34db4db':
  git-gui: chmod +x po2msg, windows/git-gui.sh
Merge commit '0f2068c4cfb8bc84d338265f03c773e5559e761d' into jn/scripts-updates

* commit '0f2068c4cfb8bc84d338265f03c773e5559e761d':
  gitk: chmod +x po2msg
transport: catch non positive --depth option value

Instead of simply ignoring the value passed to --depth option when
it is zero or negative, catch and report it as an error to let
people know that they were using the option incorrectly.  A negative
depth should be simply invalid, and under the hood depth==0 didn't
have any effect.

The change in fetch.c is needed because it was passing "0" explicitly,
knowing that it was a no-op; under this new world order, it will be
an error.

Signed-off-by: Andres G. Aragoneses <knocte@gmail.com>
Reviewed-by: Duy Nguyen <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jn/scripts-updates' into pu

I'll need to poke Paulus and Pat with the two subsystem patches
but other than that they looked all fairly straight-forward.

* jn/scripts-updates:
  remove #!interpreter line from shell libraries
  test: replace shebangs with descriptions in shell libraries
  test: make FILEMODE a lazy prereq
  contrib: remove git-p4import
  gitk: chmod +x po2msg
  git-gui: chmod +x po2msg, windows/git-gui.sh
  mark contributed hooks executable
  mark perl test scripts executable
  mark Windows build scripts executable
Merge branch 'aa/transport-non-positive-depth-only' into pu

* aa/transport-non-positive-depth-only:
  transport: catch non positive --depth option value