This trivially optimizes the two-way merge case of git-read-tree too,
which affects switching branches.

When you have tons and tons of files in your repository, but there are
only small differences in the branches (maybe just a couple of files
changed), the biggest cost of the branch switching was actually just the
index calculations.

This fixes it (timings for switching between the "testing" and "master"
branches in the 100,000 file testing-repo-from-hell, where the branches
only differ in one small file).

Before:
	[torvalds@woody bummer]$ time git checkout master
	real    0m9.919s
	user    0m8.461s
	sys     0m0.264s

After:
	[torvalds@woody bummer]$ time git checkout testing
	real    0m0.576s
	user    0m0.348s
	sys     0m0.228s

so it's easily an order of magnitude different.

This concludes the series. I think we could/should do the three-way merge
too (to speed up merges), but I'm lazy. Somebody else can do it.

The rule is very simple: you need to remove the old entry if:
 - you want to remove the file entirely
 - you replace it with a "merge conflict" entry (ie a non-stage-0 entry)

and you can avoid removing it if you either

 - keep the old one
 - or resolve it to a new one.

and these rules should all be valid for the three-way case too.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This optimizes bind_merge() and oneway_merge() to not unnecessarily
remove and re-add the old index entries when they can just get replaced
by updated ones.

This makes these operations much faster for large trees (where "large"
is in the 50,000+ file range), because we don't unnecessarily move index
entries around in the index array all the time.

Using the "bummer" tree (a test-tree with 100,000 files) we get:

Before:
	[torvalds@woody bummer]$ time git commit -m"Change one file" 50/500
	real    0m9.470s
	user    0m8.729s
	sys     0m0.476s

After:
	[torvalds@woody bummer]$ time git commit -m"Change one file" 50/500
	real    0m1.173s
	user    0m0.720s
	sys     0m0.452s

so for large trees this is easily very noticeable indeed.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This makes no changes to current code, but it allows the individual merge
functions to decide what to do about the old entry.  They might decide to
update it in place, rather than force them to always delete and re-add it.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* lt/readtree:
  Start moving unpack-trees to "struct tree_desc"

This trivial patch avoids re-hashing files that are already clean in the
index. This mirrors what commit 0781b8a9
did for "git add .", only for "git commit ." instead.

This improves the cold-cache case immensely, since we don't need to bring
in all the file contents, just the index and any files dirty in the index.

Before:

	[torvalds@woody linux]$ time git commit .
	real    1m49.537s
	user    0m3.892s
	sys     0m2.432s

After:

	[torvalds@woody linux]$ time git commit .
	real    0m14.273s
	user    0m1.312s
	sys     0m0.516s

(both after doing a "echo 3 > /proc/sys/vm/drop_caches" to get cold-cache
behaviour - even with the index optimization git still has to "lstat()"
all the files, so with a truly cold cache, bringing all the inodes in
will take some time).

[jc: trivial "return 0;" fixed]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The read_tree() function is called only from the call chain to
run "git diff --cached" (this includes the internal call made by
git-runstatus to run_diff_index()).  The function vacates stage
without any funky "merge" magic.  The caller then goes and
compares stage #1 entries from the tree with stage #0 entries
from the original index.

When adding the cache entries this way, it used the general
purpose add_cache_entry().  This function looks for an existing
entry to replace or if there is none to find where to insert the
new entry, resolves D/F conflict and all the other things.

For the purpose of reading entries into an empty stage, none of
that processing is needed.  We can instead append everything and
then sort the result at the end.

This commit changes read_tree() to first make sure that there is
no existing cache entries at specified stage, and if that is the
case, it runs add_cache_entry() with ADD_CACHE_JUST_APPEND flag
(new), and then sort the resulting cache using qsort().

This new flag tells add_cache_entry() to omit all the checks
such as "Does this path already exist?  Does adding this path
remove other existing entries because it turns a directory to a
file?" and instead append the given cache entry straight at the
end of the active cache.  The caller of course is expected to
sort the resulting cache at the end before using the result.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This reverts commit 524e5ffc.
It is reported that this change breaks formatting with docbook
1.69.

This doesn't actually change any real code, but it changes the interface
to unpack_trees() to take an array of "struct tree_desc" entries, the same
way the tree-walk.c functions do.

The reason for this is that we would be much better off if we can do the
tree-unpacking using the generic "traverse_trees()" functionality instead
of having to the special "unpack" infrastructure.

This really is a pretty minimal diff, just to change the calling
convention. It passes all the tests, and looks sane. There were only two
users of "unpack_trees()": builtin-read-tree and merge-recursive, and I
tried to keep the changes minimal.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The old behaviour was to unilaterally default to the cwd is the work tree
when GIT_DIR was set, but GIT_WORK_TREE wasn't, no matter if we are inside
the GIT_DIR, or if GIT_DIR is actually something like ../../../.git.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This attempts to force fixed-font in manpages for literal
blocks.  I have tested this with docbook 1.71 and it seems to
work as expected.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This hides the backslash at the end of line from AsciiDoc
toolchain by introducing a trailing whitespace on one line in an
illustration in git-rev-parse.txt.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

- when sending several mails I got a slightly different behaviour for the first
  mail compared to the second to last one.  The reason is that $from was
  assigned in line 608 and was not reset when beginning to handle the next
  mail.

- Email::Valid can only handle properly quoted real names, so quote arguments
  to extract_valid_address.

This patch cleans up variable naming to better differentiate between sender of
the mail and it's author.
Signed-off-by: NUwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Email::Valid does respect this considering such a mailbox specification
invalid.  b06c6bc8 addressed the issue, but
only if Email::Valid is available.
Signed-off-by: NUwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We have to load a tree difference for the purpose of testing
file patterns.  But if our branch is being created and there is no
specific base to difference against in the rule our base will be
'0'x40.  This is (usually) not a valid tree-ish object in a Git
repository, so there's nothing to difference against.

Instead of creating the empty tree and running git-diff against
that we just take the output of `ls-tree -r --name-only` and mark
every returned pathname as an add.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In some applications of the update hook a user may be allowed to
modify a branch, but only if the file level difference is also an
allowed change.  This is the commonly requested feature of allowing
users to modify only certain files.

A new repository.*.allow syntax permits granting the three basic
file level operations:

  A: file is added relative to the other tree
  M: file exists in both trees, but its SHA-1 or mode differs
  D: file is removed relative to the other tree

on a per-branch and path-name basis.  The user must also have a
branch level allow line already granting them access to create,
rewind or update (CRU) that branch before the hook will consult
any file level rules.

In order for a branch change to succeed _all_ files that differ
relative to some base (by default the old value of this branch,
but it can also be any valid tree-ish) must be allowed by file
level allow rules.  A push is rejected if any diff exists that
is not covered by at least one allow rule.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In some applications of this paranoid update hook the set of ACL
rules that need to be applied to a user can be large, and the
number of users that those rules must also be applied to can be
more than a handful of individuals.  Rather than repeating the same
rules multiple times (once for each user) we now allow users to be
members of groups, where the group supplies the list of ACL rules.
For various reasons we don't depend on the underlying OS groups
and instead perform our own group handling.

Users can be made a member of one or more groups by setting the
user.memberOf property within the "users/$who.acl" file:

  [user]
    memberOf = developer
	memberOf = administrator

This will cause the hook to also parse the "groups/$groupname.acl"
file for each value of user.memberOf, and merge any allow rules
that match the current repository with the user's own private rules
(if they had any).

Since some rules are basically the same but may have a component
differ based on the individual user, any user.* key may be inserted
into a rule using the "${user.foo}" syntax.  The allow rule does
not match if the user does not define one (and exactly one) value
for the key "foo".
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

blame-options.txt did not format multi-paragraph option description
correctly.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-cvsserver used checkout-index internally for commit and annotate.
Since a work tree is required for this to function now, this was
breaking.  Work around this by defining GIT_WORK_TREE=. in the
appropriate places.
Signed-off-by: NBrian Downing <bdowning@lavos.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Parse the files section in the "p4 change -o" output and remove lines with file changes in unrelated depot paths.
Signed-off-by: NSimon Hausmann <simon@lst.de>
Signed-off-by: NMarius Storm-Olsen <marius@trolltech.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The basic idea was proposed by Steve Hoelzer; in order to make
the list easier to search, we keep the command list in the
script that generates it with "sort -d".
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Detect symlinks as file type, set the git file mode accordingly and strip off the trailing newline in the p4 print output.
Make the mode handling a bit more readable at the same time.
Signed-off-by: NSimon Hausmann <simon@lst.de>
Acked-by: NBrian Swetland <swetland@google.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NSteve Hoelzer <shoelzer@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NSteve Hoelzer <shoelzer@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NSteven Grimm <koreth@midwinter.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Without this patch I'm not able to properly send emails as I have a
non-ascii character in my name.

I removed the _rfc822 suffix from the function name as it now does more
than rfc822 quoting.

I dug through rfc822 to do the double quoting right.  Only if that is not
possible rfc2047 quoting is applied.
Signed-off-by: NUwe Kleine-K,Av(Bnig <ukleinek@informatik.uni-freiburg.de>
Cc: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The basic idea is from Mark Levedahl.  I do not use GZ=1 nor
quick-install-doc myself (there obviously is a chicken-and-egg
issue with quick-install-doc for me).
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It was very unfortunate that we added core.pager setting to the
configuration file; even when the underlying command does not care
if there is no git repository is involved (think "git diff --no-index"),
the user would now rightfully want the configuration setting to be
honored, which means we would need to read the configuration file before
we launch the pager.

This is a minimum change in the sense that it restores the old
behaviour of not even reading config in setup_git_directory(),
but have the core.pager honored when we know it matters.

Note that this does not cover "git -p --git-dir where command";
the -p option immediately trigger the pager settings before we
even see --git-dir to learn where the configuration file is, so
we will end up reading the configuration from the place where
we would _normally_ find the git repository.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-am expects the variable $resume to be empty or unset, which might not
be the case if $resume is set in the user's environment.  So initialize
it to an empty value on startup.

The problem was noticed by Pierre Habouzit and reported through
 http://bugs.debian.org/435807Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These instructions tell you how to create a clone of a repository
created with git-svn, that can in turn be used with git-svn.
Signed-off-by: NAdam Roben <aroben@apple.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  apply: remove directory that becomes empty by renaming the last file away
  setup.c:verify_non_filename(): don't die unnecessarily while disambiguating

We attempt to remove directory that becomes empty after removal
of a file.  We should do the same when we rename an existing
file away.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If you have a working tree _file_ "foo", attempt to refer to a
branch "foo/bar" without -- to disambiguate, like this:

	$ git log foo/bar

tried to make sure that foo/bar cannot be naming a working tree
file "foo/bar" (in which case we would say "which one do you
want?  A rev or a working tree file?  clarify with -- please").
We run lstat("foo/bar") to check that.  If it does not succeed,
there is no ambiguity.

That is good.  But we also checked the error status for the
lstat() and expected it to fail with ENOENT.  In this particular
case, however, it fails with ENOTDIR.  That should be treated as
"expected error" as well.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As with git-add, I think previous updates to the git-commit man page did
indeed help make it more user-friendly.  But I think the banishment of
the word "index" from the description goes too far; reinstate its use,
to simplify some of the language slightly and smooth the transition to
other documentation.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'master' of git://linux-nfs.org/~bfields/git:
  documentation: use the word "index" in the git-add manual page
  user-manual: mention git-gui
  user-manual: mention git stash
  user-manual: update for new default --track behavior

It was a neat trick to show that you could introduce the git-add manual
page without using the word "index", and it was certainly an improvement
over the previous man page (which started out "A simple wrapper for
git-update-index to add files to the index...").

But it's possible to use the standard terminology without sacrificing
user-friendliness.  So, rewrite to use the word "index" when
appropriate.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

The git gui project seems to be still in early stages, but at a point
where it's worth mentioning as an alternative way of creating commits.

One feature of interest is the ability to manipulate individual diff
hunks.  However, people have found that feature not to be easily
discoverable from the user-interface.  Pending some ui improvements, a
parenthetical hint here may help.

(Thanks to Steffen Prohask and Junio Hamano for suggesting the
language.)
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Mention the git-stash command as a way to temporarily set aside work in
progress.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Update documentation to reflect the --track default.

That change seems to have happened in the 1.5.3 -rc's, so bump the "for
version x.y.z or newer" warning as well.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>