apply: do not leak patches and fragments

In the while loop inside apply_patch, patch and fragments are
dynamically allocated with a calloc. However, only unused patches
are actually freed and the rest are left to leak. Since a list is
actively built up consisting of the used patches, they can simply be
iterated and freed at the end of the function.

In addition, the text in fragments were not freed, primarily because
they mostly point into a patch text that is freed as a whole. But
there are some cases where new piece of memory is allocated and
pointed by a fragment (namely, when handling a binary patch).

Introduce a free_patch bitfield to mark each fragment if its text
needs to be freed, and free patches, fragments and fragment text
that need to be freed when we are done with the input.

Signed-off-by: Jared Hance <jaredhance@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log --graph --stat: three-dash separator should come after graph lines

Output from "git log --graph --stat -p" emits the three-dash separator
line before the graph that shows ancestry lines.  The separator should
come after the ancestry lines just like all the other output.

Signed-off-by: Lucian Poston <lucian.poston@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log --graph: fix break in graph lines

Output from "git log --graph --stat -p" broke the ancestry graph lines
with a single empty line between the diffstat and the patch.

Signed-off-by: Lucian Poston <lucian.poston@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t4202: add test for "log --graph --stat -p" separator lines

Add tests to make sure that the three-dash separator lines appear
after the graph ancestry lines, and also the graph ancestry lines
are not broken between the diffstat and the patch.

Signed-off-by: Lucian Poston <lucian.poston@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
difftool: parse options using Getopt::Long

Replace custom option/argument parser with standard Getopt::Long
module.  This shortens the code and makes it easier to understand.

Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
difftool: add '--no-gui' option

This commit teaches difftool to handle the '--no-gui' option. This option
negates the existing '--gui' option. The last setting given on the command
line wins.

This allows a user to configure "[alias] mdt = difftool --gui", but still
have the ability to override the setting without error:

$ git mdt --no-gui

Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
difftool: exit(0) when usage is printed

Prior to this commit, the script exited with an error whenever the
usage string was printed, regardless of the reason it was done. In
cases where usage was printed due to a user request (e.g. '-h'
option), the script should exit without error (exit 0).

This commit adds an argument to the usage function that allows the
exit code to be specified when the function is called.

Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
difftool: remove explicit change of PATH

Adding the script directory to PATH is not needed. The script is
located at '$(git --exec-path)', which is already on the PATH.

Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
difftool: stop appending '.exe' to git

The system call to Git works the same whether or not ".exe" is
appended to "git". The extra code is not necessary.

Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
difftool: eliminate setup_environment function

Removing this function shortens the code and makes it easier to read.
Now all environment variables are set as part of procedural operation.

Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: rename free_patch() to free_patch_list()

As that is the only logical name for a function that walks a list
and frees each element on it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: free patch->{def,old,new}_name fields

These were all allocated in the heap by parsing the header parts of the
patch, but we did not bother to free them.  Some used to share the memory
(e.g. copying def_name to old_name) so this is not just the matter of
adding three calls to free().

Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: release memory for fn_table

The fn_table is used to record the result of earlier patch application in
case a hand-crafted input file contains multiple patches to the same file.
Both its string key (filename) and the contents are borrowed from "struct
patch" that represents the previous application in the same apply_patch()
call, and they do not leak, but the table itself was not freed properly.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: free patch->result

This is by far the largest piece of data, much larger than the patch and
fragment structures or the three name fields in the patch structure.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: free unused fragments for submodule patch

We simply discarded the fragments that we are not going to use upon seeing
a patch to update the submodule commit bound at path that we have not
checked out.

Free these fragments, not to leak them.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach revision walking machinery to walk multiple times sequencially

Previously it was not possible to iterate revisions twice using the
revision walking api. We add a reset_revision_walk() which clears the
used flags. This allows us to do multiple sequencial revision walks.

We add the appropriate calls to the existing submodule machinery doing
revision walks. This is done to avoid surprises if future code wants to
call these functions more than once during the processes lifetime.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor submodule push check to use string list instead of integer

This allows us to tell the user which submodules have not been pushed.
Additionally this is helpful when we want to automatically try to push
submodules that have not been pushed.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: teach --recurse-submodules the on-demand option

When using this option git will search for all submodules that
have changed in the revisions to be send. It will then try to
push the currently checked out branch of each submodule.

This helps when a user has finished working on a change which
involves submodules and just wants to push everything in one go.

Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
var doc: default editor and pager are configurable at build time

Some distributors customize the fallback pager and editor used by git
commands when the user has not indicated a preference via the
core.editor/core.pager configuration or GIT_EDITOR, GIT_PAGER, VISUAL,
EDITOR, and PAGER environment variables, and git's build system
provides DEFAULT_PAGER and DEFAULT_EDITOR makefile settings to help
them with that (see v1.6.6-rc0~24, 2009-11-20).

Unfortunately those compile-time settings do not affect the
documentation, so the uninitiated user who tries to understand git by
reading the git-var(1) manpage can easily be confused when git falls
back to 'nano' and 'more' instead of 'vi' and 'less'.  Even if the
distributor patches the distributed docs to reflect the new default,
the user may read the official documentation from the git-htmldocs
repository online and be confused in the same way.

Add a few words stating that the defaults are customizable at
compile time to make the behavior crystal clear.

Reported-by: Rodrigo Silva (MestreLion) <linux@rodrigosilva.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch-pack: new --stdin option to read refs from stdin

If a remote repo has too many tags (or branches), cloning it over the
smart HTTP transport can fail because remote-curl.c puts all the refs
from the remote repo on the fetch-pack command line. This can make the
command line longer than the global OS command line limit, causing
fetch-pack to fail.

This is especially a problem on Windows where the command line limit is
orders of magnitude shorter than Linux. There are already real repos out
there that msysGit cannot clone over smart HTTP due to this problem.

Here is an easy way to trigger this problem:

	git init too-many-refs
	cd too-many-refs
	echo bla > bla.txt
	git add .
	git commit -m test
	sha=$(git rev-parse HEAD)
	tag=$(perl -e 'print "bla" x 30')
	for i in `seq 50000`; do
		echo $sha refs/tags/$tag-$i >> .git/packed-refs
	done

Then share this repo over the smart HTTP protocol and try cloning it:

	$ git clone http://localhost/.../too-many-refs/.git
	Cloning into 'too-many-refs'...
	fatal: cannot exec 'fetch-pack': Argument list too long

50k tags is obviously an absurd number, but it is required to
demonstrate the problem on Linux because it has a much more generous
command line limit. On Windows the clone fails with as little as 500
tags in the above loop, which is getting uncomfortably close to the
number of tags you might see in real long lived repos.

This is not just theoretical, msysGit is already failing to clone our
company repo due to this. It's a large repo converted from CVS, nearly
10 years of history.

Four possible solutions were discussed on the Git mailing list (in no
particular order):

1) Call fetch-pack multiple times with smaller batches of refs.

This was dismissed as inefficient and inelegant.

2) Add option --refs-fd=$n to pass a an fd from where to read the refs.

This was rejected because inheriting descriptors other than
stdin/stdout/stderr through exec() is apparently problematic on Windows,
plus it would require changes to the run-command API to open extra
pipes.

3) Add option --refs-from=$tmpfile to pass the refs using a temp file.

This was not favored because of the temp file requirement.

4) Add option --stdin to pass the refs on stdin, one per line.

In the end this option was chosen as the most efficient and most
desirable from scripting perspective.

There was however a small complication when using stdin to pass refs to
fetch-pack. The --stateless-rpc option to fetch-pack also uses stdin for
communication with the remote server.

If we are going to sneak refs on stdin line by line, it would have to be
done very carefully in the presence of --stateless-rpc, because when
reading refs line by line we might read ahead too much data into our
buffer and eat some of the remote protocol data which is also coming on
stdin.

One way to solve this would be to refactor get_remote_heads() in
fetch-pack.c to accept a residual buffer from our stdin line parsing
above, but this function is used in several places so other callers
would be burdened by this residual buffer interface even when most of
them don't need it.

In the end we settled on the following solution:

If --stdin is specified without --stateless-rpc, fetch-pack would read
the refs from stdin one per line, in a script friendly format.

However if --stdin is specified together with --stateless-rpc,
fetch-pack would read the refs from stdin in packetized format
(pkt-line) with a flush packet terminating the list of refs. This way we
can read the exact number of bytes that we need from stdin, and then
get_remote_heads() can continue reading from the same fd without losing
a single byte of remote protocol data.

This way the --stdin option only loses generality and scriptability when
used together with --stateless-rpc, which is not easily scriptable
anyway because it also uses pkt-line when talking to the remote server.

Signed-off-by: Ivan Todoroski <grnch@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>