git p4: Use git diff-tree instead of format-patch

The output of git format-patch can vary with user preferences. In
particular setting diff.noprefix will break the "git apply" that
is done as part of "git p4 submit".

Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Crestez Dan Leonard <cdleonard@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'rh/remote-hg-bzr-updates' (early part)

Unbreaks a recent breakage due to use of unquote-c-style.

This may need to be cherry-picked down to 1.8.4.x series.

* 'rh/remote-hg-bzr-updates' (early part):
  remote-hg: don't decode UTF-8 paths into Unicode objects
mark Windows build scripts executable

On Windows the convention is to rely on filename extensions to decide
whether a file is executable so Windows users are probably not relying
on the executable bit of these scripts, but on other platforms it can
be useful documentation.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mark perl test scripts executable

These scripts are not run directly as part of a normal build, so no
one noticed that they did not have the +x bit.  Mark them executable
to make it more obvious that they can be run directly (when debugging,
for example).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mark contributed hooks executable

The docs in contrib/hooks/pre-auto-gc-battery suggest:

	For example, if the hook is stored in
	/usr/share/git-core/contrib/hooks/pre-auto-gc-battery:

	chmod a+x pre-auto-gc-battery
	cd /path/to/your/repository.git
	ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
	     hooks/pre-auto-gc

Unfortunately on multi-user systems most users do not have write
access to /usr.  Better to mark the sample hooks executable in
the first place so users do not have to tweak their permissions to
use them by symlinking into .git/hooks/.

Reported-by: Olivier Berger <olivier.berger@it-sudparis.eu>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui: chmod +x po2msg, windows/git-gui.sh

The Makefile only runs po/po2msg.sh using tclsh, but because the
script has the usual tcl preamble starting with #!/bin/sh it can also
be run directly.

The Windows git-gui wrapper is usable in-place for the same reason.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: chmod +x po2msg

The Makefile only runs it using tclsh, but because the fallback po2msg
script has the usual tcl preamble starting with #!/bin/sh it can also
be run directly.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'master' into next

* master:
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>
commit-slab: document clear_$slabname()

The clear_$slabname() function was only documented by source code so
far.  Write something about it.

Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit-slab: declare functions "static inline"

This shuts up compiler warnings about unused functions.  No such
warnings are currently triggered, but if someone were to actually
use init_NAME_with_stride() as documented, they would get a warning
about init_NAME() being unused.

While there, write a comment about why the last real declaration of
the variable is without a terminating semicolon, while another
forward declarations have one.

Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SubmittingPatches: document how to handle multiple patches

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: don't decode UTF-8 paths into Unicode objects

The internal mercurial API expects ordinary 8-bit string objects, not
Unicode string objects.  With this change, the test-hg.sh unit tests
pass again.

Signed-off-by: Richard Hansen <rhansen@bbn.com>
Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with maint

* maint:
  remote-hg: don't decode UTF-8 paths into Unicode objects