The ref_remove_duplicates function was very slow at dealing with very
large numbers of refs.  This is because it was using a linear search
through all remaining refs to find any duplicates of the current ref.

Rewriting it to use a string list to keep track of which refs have
already been seen and removing duplicates when they are found is much
more efficient.
Signed-off-by: NJulian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When trying to get a list of remote tags to see if we need to fetch
any we were doing a linear search for the matching tag ref for the
tag^{} commit entries.  This proves to be incredibly slow for large
numbers of tags.  Rewrite the function so that we build up a
string_list of refs to fetch and then process that instead.

As an extreme example, for a repository with 50000 tags (and just a
single commit on a single branch), a fetch that does nothing goes from
~1m50s to ~4.1s.
Signed-off-by: NJulian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jc/maint-unpack-objects-strict:
  Fix "unpack-objects --strict"

Conflicts:
	builtin-unpack-objects.c

* tf/diff-whitespace-incomplete-line:
  xutils: Fix xdl_recmatch() on incomplete lines
  xutils: Fix hashing an incomplete line with whitespaces at the end

* jk/maint-1.6.3-checkout-unborn:
  checkout: do not imply "-f" on unborn branches

* jc/maint-checkout-index-to-prefix:
  check_path(): allow symlinked directories to checkout-index --prefix

* maint:
  http.c: avoid freeing an uninitialized pointer

* rc/maint-http-no-head-pack-check:
  http.c: avoid freeing an uninitialized pointer

An earlier 59b8d38f (http.c: remove verification of remote packs) left
the variable "url" uninitialized; "goto cleanup" codepath can free it
which is not very nice.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since OS X 10.6 the variable $SECURITYSESSIONID does not exist anymore,
so lets look for the $TERM_PROGRAM variable as backup.
Signed-off-by: NHeiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NHeiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Due to problems at cam.org, my nico@cam.org email address is no longer
valid.  From now on, nico@fluxnic.net should be used instead.
Signed-off-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A command line

    $ git archive -o my-v2.0.zip v2.0

almost certainly wants the output in zip format, even though it does not
specify any --format option.

When --format is not given, but output filename is, try to infer what
format is requested from the filename extension.  Currently this code only
knows about '.zip'.  When the format is unspecified and the filename does
not tell us, the output will be in 'tar' format as before.

Of course, an explicit --format will not trigger this guesswork.
Signed-off-by: NDmitry Potapov <dpotapov@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

James Bardin noted that the completion spewed warnings when no git config
file is present.  This is likely a bug to be fixed in git config, but it's
also good to simplify the completion code by using the --get-regexp option
as Jeff King pointed out.
Signed-off-by: NTodd Zullinger <tmz@pobox.com>
Trivially-acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The '-o' option is commonly used in many tools to specify the output file.
Typing '--output' every time is a bit too long to be a practical alternative
to redirecting output. But specifying the output name has the advantage of
making possible to guess the desired output format by filename extension.
Signed-off-by: NDmitry Potapov <dpotapov@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Test the effect of an earlier change by f7835a25 (preserve mtime of local
clone, 2009-09-12) to keep stale loose object files stale in the new
repository when a local clone is made by copying files in .git/
directory.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJohannes Gilger <heipei@hackvalue.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-push is not currently using -n for anything else, and it seems
unlikely we will want to use it to mean anything else in the future,
so add it as an alias for convenience.
Signed-off-by: NNelson Elhage <nelhage@mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

60c2993c (Documentation/git-commit.txt: describe --dry-run, 2009-08-15)
wanted to update the documentation to say that "git status" is not the
same as "git commit --dry-run" anymore, but it screwed up and also added
the description of --dry-run that was already present.

Noticed by Johannes Gilger.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJari Aalto <jari.aalto@cante.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* pk/fast-import-tars:
  import-tars: Allow per-tar author and commit message.

* pk/fast-import-dirs:
  Add script for importing bits-and-pieces to Git.

* jt/pushinsteadof:
  Add url.<base>.pushInsteadOf: URL rewriting for push only
  Wrap rewrite globals in a struct in preparation for adding another set

* jk/unwanted-advices:
  status: make "how to stage" messages optional
  push: make non-fast-forward help message configurable

* jc/merge-saner-messages:
  merge-recursive: give less scary messages when merge did not start

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A local clone without hardlinks copies all objects, including dangling
ones, to the new repository. Since the mtimes are renewed, those
dangling objects cannot be pruned by "git gc --prune", even if they
would have been old enough for pruning in the original repository.

Instead, preserve mtime during copy. "git gc --prune" will then work
in the clone just like it did in the original.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There were several unchecked use of fdopen(); replace them with xfdopen()
that checks and dies.
Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is the same fix to use write_str_in_full() helper to write a constant
string out without counting the length of it ourselves.
Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* db/vcs-helper:
  Makefile: remove remnant of separate http/https/ftp helpers
  Use a clearer style to issue commands to remote helpers
  Make the "traditionally-supported" URLs a special case
  Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
  Makefile: do not link three copies of git-remote-* programs
  Makefile: git-http-fetch does not need expat
  http-fetch: Fix Makefile dependancies
  Add transport native helper executables to .gitignore
  git-http-fetch: not a builtin
  Use an external program to implement fetching with curl
  Add support for external programs for handling native fetches

In 2d14d65c (Use a clearer style to issue commands to remote helpers,
2009-09-03) I happened to notice two changes like this:

-	write_in_full(helper->in, "list\n", 5);
+
+	strbuf_addstr(&buf, "list\n");
+	write_in_full(helper->in, buf.buf, buf.len);
+	strbuf_reset(&buf);

IMHO, it would be better to define a new function,

    static inline ssize_t write_str_in_full(int fd, const char *str)
    {
           return write_in_full(fd, str, strlen(str));
    }

and then use it like this:

-       strbuf_addstr(&buf, "list\n");
-       write_in_full(helper->in, buf.buf, buf.len);
-       strbuf_reset(&buf);
+       write_str_in_full(helper->in, "list\n");

Thus not requiring the added allocation, and still avoiding
the maintenance risk of literal string lengths.
These days, compilers are good enough that strlen("literal")
imposes no run-time cost.

Transformed via this:

    perl -pi -e \
        's/write_in_full\((.*?), (".*?"), \d+\)/write_str_in_full($1, $2)/'\
      $(git grep -l 'write_in_full.*"')
Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It's now similar wrapped the same way as in Documentation/git.txt, and
fits in a 67 characters wide terminal.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  GIT 1.6.4.3
  svn: properly escape arguments for authors-prog
  http.c: remove verification of remote packs
  grep: accept relative paths outside current working directory
  grep: fix exit status if external_grep() punts

Conflicts:
	GIT-VERSION-GEN
	RelNotes

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Previously, the call to authors-prog was not properly escaped, so any
special characters in the Subversion username, such as spaces and
semi-colons, would be interpreted by the shell rather than being passed
in as the first argument.  Now all unsafe characters are escaped using
"git rev-parse --sq-quote"

[ew: switched from "\Q..\E" to "rev-parse --sq-quote"]
Signed-off-by: NMark Lodato <lodatom@gmail.com>
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* cb/maint-1.6.3-grep-relative-up:
  grep: accept relative paths outside current working directory
  grep: fix exit status if external_grep() punts

Conflicts:
	t/t7002-grep.sh

Signed-off-by: NJunio C Hamano <gitster@pobox.com>