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

The example provided with the update-hook-example does not work on
either bash 2.05b.0(1)-release nor 3.1.17(1)-release. The matcher did
not match the lines that it advertised to match, such as:

refs/heads/bw/        linus
refs/heads/tmp/*      *

In POSIX 1003.2 regular expressions, the star (*), is not an wildcard
meaning "match everything", it matches 0 or more matches of the atom
preceding it.

So to match "refs/heads/bw/topic-branch", the matcher should be written
as "refs/heads/bw/.*" to match "refs/heads/bw/" and everything after it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This section has not been updated in a while and
--branches/--tags/--trunk options are commonly used nowadays.
Noticed-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Earlier commit ece7b749 added a test
for rebase that uses "am -3", but this adds a test to check "am -3"
itself.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NPierre Habouzit <madcoder@debian.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Commit 098e711e caused git-push to match only branches when
considering which refs to push. This patch updates the
documentation accordingly and adds a test for this behavior.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some people seem to create SVN branch names with spaces
or other shell metacharacters.
Signed-off-by: NMatthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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

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

* jc/grep-c:
  Split grep arguments in a way that does not requires to add /dev/null.

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Disable native platform text selection in "lists"
  git-gui: Paper bag fix "Commit->Revert" format arguments
  git-gui: Provide 'uninstall' Makefile target to undo an installation
  git-gui: Font chooser to handle a large number of font families
  git-gui: Make backporting changes from i18n version easier
  git-gui: Don't delete send on Windows as it doesn't exist
  git-gui: Trim trailing slashes from untracked submodule names
  git-gui: Assume untracked directories are Git submodules
  git-gui: handle "deleted symlink" diff marker
  git-gui: show unstaged symlinks in diff viewer
  git-gui: Avoid use of libdir in Makefile
  git-gui: Disable Tk send in all git-gui sessions
  git-gui: lib/index.tcl: handle files with % in the filename properly
  git-gui: Properly set the state of "Stage/Unstage Hunk" action
  git-gui: Fix detaching current branch during checkout
  git-gui: Correct starting of git-remote to handle -w option

Earlier code took Unix time and appended a few random digits.
If you are firing off many messages within a second, you could
issue the same id to different messages, which is a no-no.  If
you send out 31 messages within a single second, with random
integer taken out of rand(4200), you have about 10% chance of
producing the same message ID.

This fixes the problem by uses a prefix string which is
constant-per-invocation (time and pid), with a serial number for
each message generated by the process appended at the end.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The algorithm isn't right here: it accumulates any set of 8 spaces into
tabs even if they're separated by tabs, so

	<four spaces><tab><four spaces><tab>

is converted to

	<tab><tab><tab>

when it should be just

	<tab><tab>

So teach git-apply that a tab hides any group of less than 8 previous
spaces in a row.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Sometimes we use a Tk text widget as though it were a listbox.
This happens typically when we want to show an icon to the left
of the text label or just when a text widget is generally a better
choice then the native listbox widget.

In these cases if we want the user to have control over the selection
we implement our own "in_sel" tag that shows the selected region
and we perform our own selection management in the background
via keybindings and mouse bindings.  In such uses we don't want
the user to be able to activate the native platform selection by
dragging their mouse through the text widget.  Doing so creates a
very confusing display and the user is left wondering what it may
mean to have two different types of selection in the same widget.

Tk doesn't allow us to delete the "sel" tag that it uses internally
to manage the native selection but it will allow us to make it
invisible by setting the tag to have the same display properties
as unselected text.  So long as we don't actually use the "sel"
tag for anything in code its effectively invisible.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

"git diff" does not record index lines for pure mode changes (i.e. no
lines changed).  Therefore, apply --index-info would call out a bogus
error.

Instead, fall back to reading the info from the current index.

Incidentally, this fixes an error where git-rebase would not rebase a
commit including a pure mode change, and changes requiring a threeway
merge.

Noticed and later tested by Chris Shoemaker.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* '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>

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: 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>