* 'maint' of git://linux-nfs.org/~bfields/git:
  core-tutorial: minor cleanup
  documentation: replace Discussion section by link to user-manual chapter
  user-manual: todo updates and cleanup
  user-manual: fix introduction to packfiles
  user-manual: move packfile and dangling object discussion
  user-manual: rewrite object database discussion
  user-manual: reorder commit, blob, tree discussion
  user-manual: rewrite index discussion
  user-manual: create new "low-level git operations" chapter
  user-manual: rename "git internals" to "git concepts"
  user-manual: move object format details to hacking-git chapter
  user-manual: adjust section levels in "git internals"

Revise the introduction for concision, add pointers to the tutorial and
user manual as appropriate, delete cvsimport note from the end, as that
work's been done elsewhere already.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

The "Discussion" section has a lot of useful information, but is a
little wordy, especially for an already-long man page, and is designed
for an audience more of potential git hackers than users, which probably
doesn't make as much sense as git matures.  Also, I (perhaps foolishly)
forked a version in the user manual, which has been significantly
rewritten in an attempt to address some of the above problems.

So, remove this section and replace it by a (very terse) summary of the
original material--my attempt at the World's Shortest Git Overview--and
a reference to the appropriate chapter of the user manual.  It's
unfortunate to remove something that's been in this place for a long
time, as some people may still depend on finding it there.  But I think
we'll want to do this some day anyway.

Cc: Andreas Ericsson <ae@op5.se>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Format a couple lists.  Reminder that we may want to add submodule
documentation some day.

Actually I don't think we've previously mentioned .git/objects, so we
need a different introduction here.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

The discussions of packfiles and dangling objects both belong in the
object database section.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Rewrite the introduction.  Rewrite each section completely to make them
work in the new order, to add some examples, and to move plumbing
commands (like git-commit-tree) to the following chapter.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

The bottom-up blog, tree, commit order makes sense unless you want to
give explicit examples--it's easier to discover objects to examine if
you go in the other order....,
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Add an example using git-ls-files, standardize on the new "index"
terminology (as opposed to "cache"), attempt to clarify discussion and
make it a little shorter, avoid some unnecessary jargon ("write-back
cache").
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

The low-level index operations aren't as important to regular users as
the rest of this "git concepts" chapter; so move it into a separate
chapter, and do some minor cleanup.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

"git internals" sounds like something only git developers must know
about, but this stuff should be of wider interest.  Rename the chapter
and give it a slightly friendlier introduction.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Most of this is probably only of interest to git developers.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

The descriptions of the various object types should all be a subsection
of the "Object Database" section.

I cribbed most of this chapter from the README (now core-intro.txt and
git(7)), because there's stuff in there people need to know and I was
too lazy to rewrite it.  The audience isn't quite right, though--the
chapter is a mixture of user- and developer- level documentation that
isn't as appropriate now as it was originally.

So, reserve this chapter for stuff users need to know, and move the
source code introduction into a new "git hacking" chapter where we'll
also move any hacker-only technical details.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

We used to rely on the fact that cherry-pick would trigger the code path
to set limited = 1 in handle_commit(), when an uninteresting commit was
encountered.

However, when cherry picking between two independent branches, i.e. when
there are no merge bases, and there is only linear development (which can
happen when you cvsimport a fork of a project), no uninteresting commit
will be encountered.

So set limited = 1 when --cherry-pick was asked for.

Noticed by Martin Bähr.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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: NJunio C Hamano <gitster@pobox.com>

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: NBenoit Sigoure <tsuna@lrde.epita.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Code inspection by Linus found this.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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

A duplicate of an already existing section in the documentation of
git-filter-branch was added in commit
f95eef15.
This patch removes that redundant section.
Signed-off-by: NUlrik Sverdrup <ulrik.sverdrup@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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/440976Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The previous check caused the hook to reject as unannotated any tag
whose SHA1 starts with a zero.
Signed-off-by: NAlexandre Julliard <julliard@winehq.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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 843103d6.
Signed-off-by: NJean-Luc Herren <jlh@gmx.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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 8588452c.
Signed-off-by: NDmitry V. Levin <ldv@altlinux.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Although message-id by defintion should have surrounding angle
brackets, there is no point forcing people to type them in.
Signed-off-by: NDavid Kastrup <dak@gnu.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Remove obsolete details (core.legacyheaders is always true now).
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NCarlos Rica <jasampler@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The code to squelch empty diffs introduced by commit
fb13227e 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: NSven Verdoolaege <skimo@kotnet.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

If we're counting, a smaller number is 'fewer' not 'less'
Signed-off-by: NMike Ralphson <mike@abacus.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>