Merge branch 'lh/svn-first-parent'

* lh/svn-first-parent:
  git-svn: always use --first-parent
  git-svn: add support for --first-parent

Merge branch 'np/delta'

* np/delta:
  builtin-pack-objects.c: avoid bogus gcc warnings
  threaded delta search: proper locking for cache accounting
  threaded delta search: add pack.threads config variable
  fix threaded delta search locking
  threaded delta search: specify number of threads at run time
  threaded delta search: better chunck split point
  threaded delta search: refine work allocation
  basic threaded delta search
  rearrange delta search progress reporting
  localize window memory usage accounting
  straighten the list of objects to deltify

builtin-pack-objects.c: avoid bogus gcc warnings

These empty statement marcos can solicit bogus "statement with no effect"
warnings; squelch them.

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

Merge branch 'jc/pack'

* jc/pack:
  Keep last used delta base in the delta window

Merge branch 'dk/diff-delta'

* dk/diff-delta:
  diff-delta.c: Rationalize culling of hash buckets
  diff-delta.c: pack the index structure

Merge branch 'jc/partial-remove'

* jc/partial-remove:
  Document ls-files --with-tree=<tree-ish>
  git-commit: partial commit of paths only removed from the index
  git-commit: Allow partial commit of file removal.

Document ls-files --with-tree=<tree-ish>

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

git-commit: partial commit of paths only removed from the index

Because a partial commit is meant to be a way to ignore what are
staged in the index, "git rm --cached A && git commit A" should
just record what is in A on the filesystem.  The previous patch
made the command sequence to barf, saying that A has not been
added yet.  This fixes it.

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

Merge branch 'jc/grep-c'

* jc/grep-c:
  Split grep arguments in a way that does not requires to add /dev/null.
  Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot
  Add test to check recent fix to "git add -u"
  Documentation/git-archive.txt: a couple of clarifications.
  Fix the rename detection limit checking
  diff --no-index: do not forget to run diff_setup_done()

Split grep arguments in a way that does not requires to add /dev/null.

In order to (almost) always show the name of the file without
relying on "-H" option of GNU grep, we used to add /dev/null to
the argument list unless we are doing -l or -L.  This caused
"/dev/null:0" to show up when -c is given in the output.

It is not enough to add -c to the set of options we do not pass
/dev/null for.  When we have too many files, we invoke grep
multiple times and we need to avoid giving a widow filename to
the last invocation -- otherwise we will not see the name.

This keeps two filenames when the argv[] buffer is about to
overflow and we have not finished iterating over the index, so
that the last round will always have at least two paths to work
with (and not require /dev/null).

An obvious and the only exception is when there is only 1 file
that is given to the underlying grep, and in that case we avoid
passing /dev/null and let the external "grep -c" report only the
number of matches.

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

Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot

Bram Schoenmakers noticed that git-config document was formatted
incorrectly.  Depending on the version of AsciiDoc and docbook
toolchain, it is sometimes taken as a numbered example by AsciiDoc,
some other times passed intact to roff format to confuse "man".

Since we refer to the repository metadata directory as $GIT_DIR
elsewhere, work it around by using that symbolic name.

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

Add test to check recent fix to "git add -u"

An earlier commit fixed type-change case in "git add -u".
This adds a test to make sure we do not introduce regression.

At the same time, it fixes a stupid typo in the error message.

Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/git-archive.txt: a couple of clarifications.

The description of the option gave impression that there
were several formats available by using three dots. There are
no other formats than tar and gzip currently supported.

Clarify that the archive goes to the standard output.

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

Fix the rename detection limit checking

This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.

This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.

The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --no-index: do not forget to run diff_setup_done()

Code inspection by Linus found this.

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

Merge branch 'maint'

* maint:
  git-format-patch --in-reply-to: accept <message@id> with angle brackets
  git-add -u: do not barf on type changes
  Remove duplicate note about removing commits with git-filter-branch
  git-clone: improve error message if curl program is missing or not executable
  hooks--update: Explicitly check for all zeros for a deleted ref.

git-format-patch --in-reply-to: accept <message@id> with angle brackets

This will allow RFC-literate users to say:

format-patch --in-reply-to='<message.id@site.name>'

without forcing them to strip the surrounding angle brackets
like this:

format-patch --in-reply-to='message.id@site.name'

We accept both forms, and the latter gets necessary < and >
around it as before.

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

git-add -u: do not barf on type changes

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

Remove duplicate note about removing commits with git-filter-branch

A duplicate of an already existing section in the documentation of
git-filter-branch was added in commit
f95eef15f2f8a336b9a42749f5458c841a5a5d63.
This patch removes that redundant section.

Signed-off-by: Ulrik Sverdrup <ulrik.sverdrup@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-clone: improve error message if curl program is missing or not executable

If the curl program is not available (or not executable), and git clone is
started to clone a repository through http, this is the output

 Initialized empty Git repository in /tmp/puppet/.git/
 /usr/bin/git-clone: line 37: curl: command not found
 Cannot get remote repository information.
 Perhaps git-update-server-info needs to be run there?

This patch improves the error message by checking the return code when
running curl to exit immediately if it's 126 or 127; the error output now
is

 Initialized empty Git repository in /tmp/puppet/.git/
 /usr/bin/git-clone: line 37: curl: command not found

Adrian Bridgett noticed this and reported through
 http://bugs.debian.org/440976

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.el: Allow the add and remove commands to be applied to ignored files.

Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.el: Allow selecting whether to display uptodate/unknown/ignored files.

The default behavior for each state can be customized, and it can also
be toggled directly from the status buffer.

Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.el: Keep the status buffer sorted by filename.

This makes insertions and updates much more efficient.

Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

hooks--update: Explicitly check for all zeros for a deleted ref.

The previous check caused the hook to reject as unannotated any tag
whose SHA1 starts with a zero.

Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-commit: Allow partial commit of file removal.

When making a partial commit, git-commit uses git-ls-files with
the --error-unmatch option to expand and sanity check the user
supplied path patterns.  When any path pattern does not match
with the paths known to the index, it errors out, in order to
catch a common mistake to say "git commit Makefiel cache.h"
and end up with a commit that touches only cache.h (notice the
misspelled "Makefile").  This detection however does not work
well when the path has already been removed from the index.

If you drop a path from the index and try to commit that
partially, i.e.

$ git rm COPYING
$ git commit -m 'Remove COPYING' COPYING

the command complains because git does not know anything about
COPYING anymore.

This introduces a new option --with-tree to git-ls-files and
uses it in git-commit when we build a temporary index to
write a tree object for the partial commit.

When --with-tree=<tree-ish> option is specified, names from the
given tree are added to the set of names the index knows about,
so we can treat COPYING file in the example as known.

Of course, there is no reason to use "git rm" and git-aware
people have long time done:

$ rm COPYING
$ git commit -m 'Remove COPYING' COPYING

which works just fine.  But this caused a constant confusion.

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

Merge branch 'maint'

* maint:
  stash: end index commit log with a newline
  git-commit: Disallow amend if it is going to produce an empty non-merge commit
  git-send-email.perl: Add angle brackets to In-Reply-To if necessary
  Fix a test failure (t9500-*.sh) on cygwin

Merge branch 'sp/maint-no-thin' into maint

* sp/maint-no-thin:
  Make --no-thin the default in git-push to save server resources

Define NO_MEMMEM of FreeBSD as it lacks the function

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

threaded delta search: proper locking for cache accounting

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash: end index commit log with a newline

There was no newline at the end of the index commit message, putting
the shell prompt at its end after a 'git cat-file commit $id'.  This is
similar to what was fixed in 843103d69388a5c74ed99753e1c162a66835b04d.

Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-commit: Disallow amend if it is going to produce an empty non-merge commit

Right now one can amend the last non-merge commit using a dirty index
and in the process maybe cause the last commit to have the same tree
as its parent.  In such a case one would want to discard the last commit
instead of amending it.

This reverts commit 8588452ceb78b1da17652ba03f9942ef740e07ea.

Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-send-email.perl: Add angle brackets to In-Reply-To if necessary

Although message-id by defintion should have surrounding angle
brackets, there is no point forcing people to type them in.

Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix a test failure (t9500-*.sh) on cygwin

On filesystems where it is appropriate to set core.filemode
to false, test 29 ("commitdiff(0): mode change") fails when
git-commit does not notice a file (execute) permission change.

A fix requires noting the new file execute permission in the
index with a "git update-index --chmod=+x", prior to the commit.
Add a function (note_chmod) which implements this idea, and
insert a call in each test that modifies the x permission.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

threaded delta search: add pack.threads config variable

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fix threaded delta search locking

Found by Jeff King.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'rs/archive'

* rs/archive:
  archive - leakfix for format_subst()
  Define NO_MEMMEM on Darwin as it lacks the function
  archive: rename attribute specfile to export-subst
  archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR" (take 2)
  add memmem()
  Remove unused function convert_sha1_file()
  archive: specfile support (--pretty=format: in archive files)
  Export format_commit_message()

archive - leakfix for format_subst()

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

Merge branch 'sp/maint-no-thin'

* sp/maint-no-thin:
  Make --no-thin the default in git-push to save server resources
  fix doc for --compression argument to pack-objects
  git-tag -s must fail if gpg cannot sign the tag.

Make --no-thin the default in git-push to save server resources

1) pushes happen less often than fetches, so the bandwidth saving is
   much less visible in that case overall.

2) thin packs have to be complemented with missing delta bases to be
   valid, so many received thin packs will take more disk space.

3) the bother of repacking should be distributed amongst "clients"
   i.e. fetchers and pushers as much as possible, and not the server
   being fetched or pushed, to keep disk and CPU usage low on the
   server.

This is why a fetch should get thin packs but a push should not.

Both Nico and I have been assuming that --no-thin was the default
behavior of git-push ever since Nico introduced --fix-thin into the
index-pack process, which allowed fetch and receive-pack to avoid
exploding packfiles received during transfer.  This patch finally
makes it so.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fix doc for --compression argument to pack-objects

Remove obsolete details (core.legacyheaders is always true now).

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

threaded delta search: specify number of threads at run time

This adds a --threads=<n> parameter to 'git pack-objects' with
documentation.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

threaded delta search: better chunck split point

Try to keep object with the same name hash together.

Suggested by Martin Koegler.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

threaded delta search: refine work allocation

With this, each thread get repeatedly assigned the next available chunk of
objects to process until the whole list is done.  The idea is to have
reasonably small chunks so that all CPUs remain busy with a minimum
number of threads for as long as there is data to process.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-tag -s must fail if gpg cannot sign the tag.

Most of this patch code and message was written by Shawn O. Pearce.
I made some tests to know what the problem was, and then I changed
the code related with the SIGPIPE signal.

If the user has misconfigured `user.signingkey` in their .git/config
or just doesn't have any secret keys on their keyring and they ask
for a signed tag with `git tag -s` we better make sure the resulting
tag was actually signed by gpg.

Prior versions of builtin git-tag allowed this failure to slip
by without error as they were not checking the return value of
the finish_command() so they did not notice when gpg exited with
an error exit status.  They also did not fail if gpg produced an
empty output or if read_in_full received an error from the read
system call while trying to read the pipe back from gpg.

Finally, we did not actually honor any return value from the do_sign
function as it returns ssize_t but was being stored into an unsigned
long.  This caused the compiler to optimize out the die condition,
allowing git-tag to continue along and create the tag object.

However, when gpg gets a wrong username, it exits before any read was done
and then the writing process receives SIGPIPE and program is terminated.
By ignoring this signal, anyway, the function write_or_die gets EPIPE from
write_in_full and exits returning 0 to the system without a message.
Here we better call to write_in_full directly so we can fail
printing a message and return safely to the caller.

With these issues fixed `git-tag -s` will now fail to create the
tag and will report a non-zero exit status to its caller, thereby
allowing automated helper scripts to detect (and recover from)
failure if gpg is not working properly.

Proposed-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-delta.c: Rationalize culling of hash buckets

The previous hash bucket culling resulted in a somewhat unpredictable
number of hash bucket entries in the order of magnitude of HASH_LIMIT.

Replace this with a Bresenham-like algorithm leaving us with exactly
HASH_LIMIT entries by uniform culling.

Signed-off-by: David Kastrup <dak@gnu.org>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-delta.c: pack the index structure

In normal use cases, the performance wins are not overly impressive:
we get something like 5-10% due to the slightly better locality of
memory accesses using the packed structure.

However, since the data structure for index entries saves 33% of
memory on 32-bit platforms and 40% on 64-bit platforms, the behavior
when memory gets limited should be nicer.

This is a rather well-contained change.  One obvious improvement would
be sorting the elements in one bucket according to their hash, then
using binary probing to find the elements with the right hash value.

As it stands, the output should be strictly the same as previously
unless one uses the option for limiting the amount of used memory, in
which case the created packs might be better.

Signed-off-by: David Kastrup <dak@gnu.org>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  git-svn: understand grafts when doing dcommit
  git-diff: don't squelch the new SHA1 in submodule diffs
  git-svn: fix "Malformed network data" with svn:// servers
  (cvs|svn)import: Ask git-tag to overwrite old tags.
  Documentation / grammer nit

git-svn: understand grafts when doing dcommit

Use the rev-list --parents functionality to read the parents
of the commit.  cat-file only shows the raw object with the
original parents and doesn't take into account grafts; so
we'll rely on rev-list machinery for the smarts here.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-diff: don't squelch the new SHA1 in submodule diffs

The code to squelch empty diffs introduced by commit
fb13227e089f22dc31a3b1624559153821056848 would inadvertently
populate filespec "two" of a submodule change using the uninitialized
(null) SHA1, thereby replacing the submodule SHA1 by 0{40} in the output.

This change teaches diffcore_skip_stat_unmatch to handle
submodule changes correctly.

Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Define NO_MEMMEM on Darwin as it lacks the function

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: fix "Malformed network data" with svn:// servers

We have a workaround for the reparent function not working
correctly on the SVN native protocol servers.  This workaround
opens a new connection (SVN::Ra object) to the new
URL/directory.

Since libsvn appears limited to only supporting one connection
at a time, this workaround invalidates the Git::SVN::Ra object
that is $self inside gs_fetch_loop_common().  So we need to
restart that connection once all the fetching is done for each
loop iteration to be able to run get_log() successfully.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

(cvs|svn)import: Ask git-tag to overwrite old tags.

If the tag was moved in CVS or SVN history, it will be moved in the
imported history as well. Tag history is not tracked.

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

git-rebase: fix -C option

The extra shift here causes failure to parse any commandline including
the -C option.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-rebase: support --whitespace=<option>

Pass --whitespace=<option> to git-apply.  Since git-apply and git-am
expect this, I'm always surprised when I try to give it to git-rebase
and it doesn't work.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation / grammer nit

If we're counting, a smaller number is 'fewer' not 'less'

Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: always use --first-parent

This makes git-svn unconditionally invoke git-log with --first-parent when
it is trying to discover its upstream subversion branch and collecting the
commit ids which should be pushed to it with dcommit. The reason for always
using --first-parent is to make git-svn behave in a predictable way when the
ancestry chain contains merges with other git-svn branches.

Since git-svn now always uses 'git-log --first-parent' there is no longer
any need for the --first-parent option to git-svn, so this is removed.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

archive: rename attribute specfile to export-subst

As suggested by Junio and Johannes, change the name of the former
attribute specfile to export-subst to indicate its function rather
than purpose and to make clear that it is not applied to working tree
files.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR" (take 2)

As suggested by Johannes, --pretty=format: placeholders in specfiles
need to be wrapped in $Format:...$ now.  This syntax change restricts
the expansion of placeholders and makes it easier to use with files
that contain non-placeholder percent signs.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add memmem()

memmem() is a nice GNU extension for searching a length limited string
in another one.

This compat version is based on the version found in glibc 2.2 (GPL 2);
I only removed the optimization of checking the first char by hand, and
generally tried to keep the code simple.  We can add it back if memcmp
shows up high in a profile, but for now I prefer to keep it (almost
trivially) simple.

Since I don't really know which platforms beside those with a glibc
have their own memmem(), I used a heuristic: if NO_STRCASESTR is set,
then NO_MEMMEM is set, too.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of git://repo.or.cz/git/git-p4

* 'master' of git://repo.or.cz/git/git-p4:
  git-p4: Added support for automatically importing newly appearing perforce branches.
  git-p4: Cleanup; moved the (duplicated) code for turning a branch into a git ref (for example foo -> refs/remotes/p4/<project>/foo) into a separate method.
  git-p4: Cleanup; moved the code for the initial #head or revision import into a separate function, out of P4Sync.run.
  git-p4: Cleanup; Turn self.revision into a function local variable (it's not used anywhere outside the function).
  git-p4: Cleanup; moved the code to import a list of p4 changes using fast-import into a separate member function of P4Sync.
  git-p4: Cleanup; moved the code for getting a sorted list of p4 changes for a list of given depot paths into a standalone method.
  git-p4: After submission to p4 always synchronize from p4 again (into refs/remotes). Whether to rebase HEAD or not is still left as question to the end-user.
  git-p4: Always call 'p4 sync ...' before submitting to Perforce.

basic threaded delta search

this is still rough, hence it is disabled by default.  You need to compile
with "make THREADED_DELTA_SEARCH=1 ..." at the moment.

Threading is done on different portions of the object list to be
deltified. This is currently done by spliting the list into n parts and
then a thread is spawned for each of them.  A better method would consist
of spliting the list into more smaller parts and have the n threads
pick the next part available.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rearrange delta search progress reporting

This is to help threadification of the delta search code, with a bonus
consistency check.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

localize window memory usage accounting

This is to help threadification of delta searching.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

straighten the list of objects to deltify

Not all objects are subject to deltification, so avoid carrying those
along, and provide the real count to progress display.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  Include a git-push example for creating a remote branch
  Cleanup unnecessary file modifications in t1400-update-ref
  Makefile: Add cache-tree.h to the headers list
  Don't allow contrib/workdir/git-new-workdir to trash existing dirs
  git-apply: do not read past the end of buffer

Include a git-push example for creating a remote branch

Many users get confused when `git push origin master:foo` works
when foo already exists on the remote repository but are confused
when foo doesn't exist as a branch and this form does not create
the branch foo.

This new example highlights the trick of including refs/heads/
in front of the desired branch name to create a branch.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Cleanup unnecessary file modifications in t1400-update-ref

Kristian Høgsberg pointed out that the two file modifications
we were doing during the 'creating initial files' step are not even
used within the test suite.  This was actually confusing as we do
not even need these changes for the tests to pass.  All that really
matters here is the specific commit dates are used so that these
appear in the branch's reflog, and that the dates are different so
that the branch will update when asked and the reflog entry is
also updated.  There is no need for the file modification.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: Add cache-tree.h to the headers list

The dependency was missing.

Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Don't allow contrib/workdir/git-new-workdir to trash existing dirs

Recently I found that doing a sequence like the following:

  git-new-workdir a b
  ...
  git-new-workdir a b

by accident will cause a (and now also b) to have an infinite cycle
in its refs directory.  This is caused by git-new-workdir trying
to create the "refs" symlink over again, only during the second
time it is being created within a's refs directory and is now also
pointing back at a's refs.

This causes confusion in git as suddenly branches are named things
like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the
more commonly accepted "refs/heads/foo".  Plenty of commands start
to see ambiguous ref names and others just take ages to compute.

git-clone has the same safety check, so git-new-workdir should
behave just like it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-apply: do not read past the end of buffer

When the preimage we are patching is shorter than what the patch
text expects, we tried to match the buffer contents at the
"original" line with the fragment in full, without checking we
have enough data to match in the preimage.  This caused the size
of a later memmove() to wrap around and attempt to scribble
almost the entire address space.  Not good.

The code that follows the part this patch touches tries to match
the fragment with line offsets.  Curiously, that code does not
have the problem --- it guards against reading past the end of
the preimage.

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

git-svn: add support for --first-parent

When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit
messages, it can get confused when local history contains merges with
other git-svn branches. But if --first-parent is supplied to git-log,
working_head_info() will only see 'branch-local' commits and thus the
first commit containing a 'git-svn-id' line should refer to the correct
subversion branch.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ds/sendmail'

* ds/sendmail:
  send-email: Add support for SSL and SMTP-AUTH

Function for updating refs.

A function intended to be called from builtins updating refs
by locking them before write, specially those that came from
scripts using "git update-ref".

[jc: with minor fixups]

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Remove unused function convert_sha1_file()

convert_sha1_file() became unused by the previous patch -- remove it.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

archive: specfile support (--pretty=format: in archive files)

Add support for a new attribute, specfile.  Files marked as being
specfiles are expanded by git-archive when they are written to an
archive.  It has no effect on worktree files.  The same placeholders
as those for the option --pretty=format: of git-log et al. can be
used.

The attribute is useful for creating auto-updating specfiles.  It is
limited by the underlying function format_commit_message(), though.
E.g. currently there is no placeholder for git-describe like output,
and expanded specfiles can't contain NUL bytes.  That can be fixed
in format_commit_message() later and will then benefit users of
git-log, too.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Export format_commit_message()

Drop the parameter "msg" of format_commit_message() (as it can be
inferred from the parameter "commit"), add a parameter "template"
in order to avoid accessing the static variable user_format
directly and export the result.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: Added support for automatically importing newly appearing perforce branches.

If a change in a p4 "branch" appears that hasn't seen any previous commit and
that has a known branch mapping we now try to import it properly. First we
find the p4 change of the source branch that the new p4 branch is based on. Then
we using git rev-list --bisect to locate the corresponding git commit to that change.
Finally we import all changes in the new p4 branch up to the current change and resume
with the regular import.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; moved the (duplicated) code for turning a branch into a git ref (for example foo -> refs/remotes/p4/<project>/foo) into a separate method.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; moved the code for the initial #head or revision import into a separate function, out of P4Sync.run.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; Turn self.revision into a function local variable (it's not used anywhere outside the function).

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; moved the code to import a list of p4 changes using fast-import into a separate member function of P4Sync.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; moved the code for getting a sorted list of p4 changes for a list of given depot paths into a standalone method.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: After submission to p4 always synchronize from p4 again (into refs/remotes). Whether to rebase HEAD or not is still left as question to the end-user.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Always call 'p4 sync ...' before submitting to Perforce.

Acked-by: Marius Storm-Olsen <marius@trolltech.com>
Acked-by: Thiago Macieira <thiago@kde.org>

send-email: Add support for SSL and SMTP-AUTH

Allows username and password to be given using --smtp-user
and --smtp-pass. SSL use is flagged by --smtp-ssl. These are
backed by corresponding defaults in the git configuration file.

This implements Junio's 'mail identity' suggestion in a slightly
more generalised manner. --identity=$identity, backed by
sendemail.identity indicates that the configuration subsection
[sendemail "$identity"] should take priority over the [sendemail]
section for all configuration values.

Signed-off-by: Douglas Stockwell <doug@11011.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start 1.5.4 cycle

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

GIT 1.5.3.1: obsolete git-p4 in RPM spec file.

HPA noticed that yum does not like the newer git RPM set; it turns out
that we do not ship git-p4 anymore but existing installations do not
realize the package is gone if we do not tell anything about it.

David Kastrup suggests using Obsoletes in the spec file of the new
RPM to replace the old package, so here is a try.

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

Typofix: 1.5.3 release notes

GIT 1.5.3

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

Keep last used delta base in the delta window

This is based on Martin Koegler's idea to keep the object that
was successfully used as the base of the delta when it is about
to fall off the edge of the window.  Instead of doing so only
for the objects at the edge of the window, this makes the window
a lru eviction mechanism.  If an entry is used as a base, it is
moved to the last of the queue to be evicted.

This is a quick-and-dirty implementation, as it keeps the original
implementation of the data structure used for the window.  This
originally was done as an array, not as an array of pointers,
because it was meant to be used as a cyclic FIFO buffer and a
plain array avoids an extra pointer indirection, while its FIFOness
eant that we are not "moving" the entries like this patch does.

The runtime from three versions were comparable.  It seems to
make the resulting chain even shorter, which can only be good.

(stock "master") 15782196 bytes
chain length = 1: 2972 objects
chain length = 2: 2651 objects
chain length = 3: 2369 objects
chain length = 4: 2121 objects
chain length = 5: 1877 objects
...
chain length = 46: 490 objects
chain length = 47: 515 objects
chain length = 48: 527 objects
chain length = 49: 570 objects
chain length = 50: 408 objects

(with your patch) 15745736 bytes (0.23% smaller)
chain length = 1: 3137 objects
chain length = 2: 2688 objects
chain length = 3: 2322 objects
chain length = 4: 2146 objects
chain length = 5: 1824 objects
...
chain length = 46: 503 objects
chain length = 47: 509 objects
chain length = 48: 536 objects
chain length = 49: 588 objects
chain length = 50: 357 objects

(with this patch) 15612086 bytes (1.08% smaller)
chain length = 1: 4831 objects
chain length = 2: 3811 objects
chain length = 3: 2964 objects
chain length = 4: 2352 objects
chain length = 5: 1944 objects
...
chain length = 46: 327 objects
chain length = 47: 353 objects
chain length = 48: 304 objects
chain length = 49: 298 objects
chain length = 50: 135 objects

[jc: this is with code simplification follow-up from Nico]

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

Merge branch 'jp/send-email-cc'

* jp/send-email-cc:
  git-send-email --cc-cmd

Mention -m as an abbreviation for --merge

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update my contact address as the maintainer.

Documentation: minor AsciiDoc mark-up fixes.

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

URL: allow port specification in ssh:// URLs

Allow port specification in ssh:// URLs in the
usual notation:

ssh://[user@]host.domain[:<port>]/<path>

This allows git to be used over ssh-tunneling
networks.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Avoid one-or-more (\+) non BRE in sed scripts.

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

rebase -m: Fix incorrect short-logs of already applied commits.

When a topic branch is rebased, some of whose commits are already
cherry-picked upstream:

    o--X--A--B--Y    <- master
     \
      A--B--Z        <- topic

then 'git rebase -m master' would report:

    Already applied: 0001 Y
    Already applied: 0002 Y

With this fix it reports the expected:

    Already applied: 0001 A
    Already applied: 0002 B

As an added bonus, this change also avoids 'echo' of a commit message,
which might contain escapements.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-diff: resurrect the traditional empty "diff --git" behaviour

The warning message to suggest "Consider running git-status" from
"git-diff" that we experimented with during the 1.5.3 cycle turns
out to be a bad idea.  It robbed cache-dirty information from people
who valued it, while still asking users to run "update-index --refresh".
It was hoped that the new behaviour would at least have some educational
value, but not showing the cache-dirty paths like before meant that the
user would not even know easily which paths were cache-dirty, and it
made the need to refresh the index look like even more unnecessary chore.

This commit reinstates the traditional behaviour, but with a twist.

By default, the empty "diff --git" output is totally squelched out
from "git diff" output.  At the end of the command, it automatically
runs "update-index --refresh" as needed, without even bothering the
user.  In other words, people who do not care about the cache-dirtyness
do not even have to see the warning.

The traditional behaviour to see the stat-dirty output and to bypassing
the overhead of content comparison can be specified by setting the
configuration variable diff.autorefreshindex to false.

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

git-tag: Fix -l option to use better shell style globs.

This patch removes certain behaviour of "git tag -l foo", currently
listing every tag name having "foo" as a substring.  The same
thing now could be achieved doing "git tag -l '*foo*'".

This feature was added recently when git-tag.sh got the -n option
for showing tag annotations, because that commit also replaced the
old "grep pattern" behaviour with a more preferable "shell pattern"
behaviour (although slightly modified as you can see).
Thus, the following builtin-tag.c implemented it in order to
ensure that tests were passing unchanged with both programs.

Since common "shell patterns" match names with a given substring
_only_ when * is inserted before and after (as in "*substring*"), and
the "plain" behaviour cannot be achieved easily with the current
implementation, this is mostly the right thing to do, in order to
make it more flexible and consistent.

Tests for "git tag" were also changed to reflect this.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: fix dcommit clobbering upstream when committing multiple changes

Although dcommit could detect if the first commit in the series
would conflict with the HEAD revision in SVN, it could not
detect conflicts in further commits it made.

Now we rebase each uncommitted change after each revision is
committed to SVN to ensure that we are up-to-date.  git-rebase
will bail out on conflict errors if our next change cannot be
applied and committed to SVN cleanly, preventing accidental
clobbering of changes on the SVN-side.

--no-rebase users will have trouble with this, and are thus
warned if they are committing more than one commit.  Fixing this
for (hopefully uncommon) --no-rebase users would be more complex
and will probably happen at a later date.

Thanks to David Watson for finding this and the original test.

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