There was a stale comment that explains why the old code could
undercount when delta data copied things around inside detination
buffer.  We do not use that kind of delta, so the comment does
not apply.

* jc/empty-commit:
  t6000: fix a careless test library add-on.
  Do not allow empty name or email.

This revamps the git-status command to take the same set of
parameters as git commit.  It gives a preview of what is being
committed with that command.  With -v flag, it shows the diff
output between the HEAD commit and the index that would be
committed if these flags were given to git-commit command.

git-commit also acquires -v flag (it used to mean "verify" but
that is the default anyway and there is --no-verify to turn it
off, so not much is lost), which uses the updated git-status -v
to seed the commit log buffer.  This is handy for writing a log
message while reviewing the changes one last time.

Now, git-commit and git-status are internally share the same
implementation.

Unlike previous git-commit change, this uses a temporary index
to prepare the index file that would become the real index file
after a successful commit, and moves it to the real index file
once the commit is actually made.  This makes it safer than the
previous scheme, which stashed away the original index file and
restored it after an aborted commit.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/ls-files-o:
  ls-files: honour per-directory ignore file from higher directories.

This matches the count_delta() logic to the change previous
commit introduces to patch_delta().
Signed-off-by: NJunio C Hamano <junkio@cox.net>

After experimenting with code to add the ability to encode a delta
against part of the deltified file, it turns out that resulting packs
are _bigger_ than when this ability is not used.  The raw delta output
might be smaller, but it doesn't compress as well using gzip with a
negative net saving on average.

Said bit would in fact be more useful to allow for encoding the copying
of chunks larger than 64KB providing more savings with large files.
This will correspond to packs version 3.

While the current code still produces packs version 2, it is made future
proof so pack versions 2 and 3 are accepted.  Any pack version 2 are
compatible with version 3 since the redefined bit was never used before.
When enough time has passed, code to use that bit to produce version 3
packs could be added.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Use stat() to explicitly check for existence rather than
relying on the non-portable EEXIST error in sha1_file.c's
safe_create_leading_directories().  There certainly are
optimizations possible, but then the code becomes almost
the same as that in coreutil's lib/mkdir-p.c.

Other uses of EEXIST seem ok.  Tested on Solaris 8, AIX 5.2L,
and a few Linux versions.  AIX has some unrelated (I think)
failures right now; I haven't tried many recent gits there.
Anyone have an old Ultrix box to break everything?  ;)

Also remove extraneous #includes.  Everything's already in
git-compat-util.h, included through cache.h.
Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If you call setup_git_directory() to work from a subdirectory,
that should be run first before running git_config().  Otherwise
you would not read the configuration file from the correct place.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJon Loeliger <jdl@jdl.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When git-ls-files -o --exclude-per-directory=.gitignore is run
from a subdirectory, it did not read from .gitignore from its
parent directory.  Reading from them makes output from these two
commands consistent:

    $ git ls-files -o --exclude-per-directory=.gitignore Documentation
    $ cd Documentation &&
      git ls-files -o --exclude-per-directory=.gitignore
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It tried to "restore" GIT_AUTHOR_EMAIL environment variable but
the variable started out as unset, so ended up setting it to an
empty string.  This is now caught as an error.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Instead of silently allowing to create a bogus commit that lacks
information by mistake, complain loudly and die.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The "--cc" implies "-p", but without the recursive part.

		Linus
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In fetch_object, there's a call to release an object request if the
object mysteriously arrived, say in a pack.  Unfortunately, the fetch
attempt for this object might already be in progress, and we'll leak the
descriptor.  Instead, try to tidy away the request.
Signed-off-by: NMark Wooding <mdw@distorted.org.uk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Don't mention it in docs or --help output.
Remove mbox, date and author variables from git-format-patch.sh.

Use DESCRIPTION text from man-page to update LONG_USAGE output. It's
a bit silly to have two texts saying the same thing in different words,
and I'm too lazy to update both.
Signed-off-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Use git-diff-tree --cc for showing the diffs for merges
  gitk: Add braces around if expressions

Introduce --only flag to allow the new "partial commit"
semantics when paths are specified.  The default is still the
traditional --include semantics.  Once peoples' fingers and
scripts that want the traditional behaviour are updated to
explicitly say --include, we could change it to either default
to --only, or refuse to operate without either --only/--include
when paths are specified.

This also fixes a couple of bugs in the previous round.  Namely:

 - forgot to save/restore index in some cases.

 - forgot to use the temporary index to show status when '--only
   paths...' semantics was used.

 - --author did not take precedence when reusing an existing
   commit.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

 - "git commit" without _any_ parameter keeps the traditional
   behaviour.  It commits the current index.

   We commit the whole index even when this form is run from a
   subdirectory.

 - "git commit --include paths..." (or "git commit -i paths...")
   is equivalent to:

   	git update-index --remove paths...
        git commit

 - "git commit paths..." acquires a new semantics.  This is an
   incompatible change that needs user training, which I am
   still a bit reluctant to swallow, but enough people seem to
   have complained that it is confusing to them.  It

   1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds
      trained git users that the traditional semantics now needs
      -i flag.

   2. refuses to run if named paths... are different in HEAD and
      the index (ditto about reminding).  Added paths are OK.

   3. reads HEAD commit into a temporary index file.

   4. updates named paths... from the working tree in this
      temporary index.

   5. does the same updates of the paths... from the working
      tree to the real index.

   6. makes a commit using the temporary index that has the
      current HEAD as the parent, and updates the HEAD with this
      new commit.

 - "git commit --all" can run from a subdirectory, but it updates
   the index with all the modified files and does a whole tree
   commit.

 - In all cases, when the command decides not to create a new
   commit, the index is left as it was before the command is
   run.  This means that the two "git diff" in the following
   sequence:

       $ git diff
       $ git commit -a
       $ git diff

   would show the same diff if you abort the commit process by
   making the commit log message empty.

This commit also introduces much requested --author option.

	$ git commit --author 'A U Thor <author@example.com>'
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In a workflow that employs relatively long lived topic branches,
the developer sometimes needs to resolve the same conflict over
and over again until the topic branches are done (either merged
to the "release" branch, or sent out and accepted upstream).

This commit introduces a new command, "git rerere", to help this
process by recording the conflicted automerge results and
corresponding hand-resolve results on the initial manual merge,
and later by noticing the same conflicted automerge and applying
the previously recorded hand resolution using three-way merge.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In addition to the branch names, populate the log message with
one-line description from actual commits that are being merged.

This was prompted by Len's 12-way octopus.  You need to have
'merge.summary' in the configuration file to enable it:

	$ git repo-config merge.summary yes
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A new flag --aggressive resolves what we traditionally resolved
with external git-merge-one-file inside index while read-tree
3-way merge works.

git-merge-octopus and git-merge-resolve use this flag before
running git-merge-index with git-merge-one-file.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If the first part uses quoted-printable to protect iso8859-1
name in the commit log, and the second part was plain ascii text
patchfile without even Content-Transfer-Encoding subheader, we
incorrectly tried to decode the patch as quoted printable.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Minor git-push copyediting
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The sections on git urls and remotes files in the git-fetch,
git-pull, and git-push manpages seem long enough to be worth a
manpage section of their own.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The push and pull man pages include a bunch of shared text from
pull-fetch-param.txt.  This simplifies maintenance somewhat, but
there's actually quite a bit of text that applies only to one or the
other.

So, separate out the push- and pull/fetch-specific text into
pull-fetch-param.txt and git-push.txt, then include the largest chunk
of common stuff (the description of protocols and url's) from
urls.txt.  That cuts some irrelevant stuff from the man pages without
making us duplicate too much.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When we remove a file, the parents' contents are all removed so
it is not that interesting to show all of them, but the fact it
was removed when all parents had it *is* unusual.  When we add a
file, similarly the fact it was added when no parent wanted it
*is* unusual, and in addition the result matters, so show it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This replaces a lot of code that used the result from several 2-way
diffs to generate a combined diff for a merge.  Now we just use
git-diff-tree --cc and colorize the output a bit, which is a lot
simpler, and has the enormous advantage that if the diff doesn't
show quite what someone thinks it should show, I can deflect the
blame to someone else. :)
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Apparently this simplifies things for the parser/compiler and makes
it go slightly faster (since without the braces, it potentially has
to do two levels of substitutions rather than one).
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

When we run combined diff from working tree (diff-files --cc),
we sent NULL to printf that is returned by find_unique_abbrev().
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We still talked about HEAD symlinks but these days we use
symrefs by default.

Also 'failed/prevented' message is now gone from the merge
output.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

These flags ask diff with a specific unmerged stage, so it
should fall back on -p instead.  Also when -c is given, we
should not do --cc.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/diff:
  git-diff-tree --stdin: show all parents.
  combine-diff: remove misguided --show-empty hack.

* lt/show:
  git-show

* lt/revlist:
  rev-parse lstat() workaround cleanup.

* jc/daemon:
  daemon: extend user-relative path notation.
  daemon: Set SO_REUSEADDR on listening sockets.
  daemon: do not forbid user relative paths unconditionally under --base-path

* mw/http:
  http-fetch: Tidy control flow in process_alternate_response
  http: Turn on verbose Curl messages if GIT_CURL_VERBOSE set in environment
  http-fetch: Fix message reporting rename of object file.
  http-fetch: Fix object list corruption in fill_active_slots().

git-diff-tree --stdin ignored second and subsequent parents when
fed git-rev-list --parents output.  Update diff_tree_commit()
function to take a commit object, and pass a fabricated commit
object after grafting the fake parents from diff_tree_stdin().
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Now --always flag is available in diff-tree, there is no reason
to have that hack in the diffcore side.
Signed-off-by: NJunio C Hamano <junkio@cox.net>