Fix and improve t7004 (git-tag tests)

Brown paper bag fix to avoid using non portable sed syntax. The
test by itself didn't catch what it was supposed to, anyways.

The new test first checks if git-tag correctly errors out when
the user exited the editor without editing the file.  Then it
checks if what the user was presented in the editor was any
useful, which we define as the following:

 * It begins with a single blank line, where the invoked editor
   would typically place the editing curser at, so that the user
   can immediately start typing;

 * It has some instruction but that comes after that initial
   blank line, all lines prefixed with "#".  We specifically do
   not check for the wording of this instruction.

 * And it has nothing else, as the expected behaviour is "Hey
   you did not leave any message".

Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: fix git-clone manpage not to refer to itself

Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual.txt: minor clarification.

Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  Update draft release notes for 1.5.3.6
  Fix per-directory exclude handing for "git add"
  core.excludesfile clean-up
  Fix t9101 test failure caused by Subversion "auto-props"
  git-send-email: add charset header if we add encoded 'From'

Update draft release notes for 1.5.3.6

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

Merge branch 'ds/maint-deflatebound' into maint

* ds/maint-deflatebound:
  Improve accuracy of check for presence of deflateBound.

Fix per-directory exclude handing for "git add"

In "dir_struct", each exclusion element in the exclusion stack records a
base string (pointer to the beginning with length) so that we can tell
where it came from, but this pointer is just pointing at the parameter
that is given by the caller to the push_exclude_per_directory()
function.

While read_directory_recursive() runs, calls to excluded() makes use
the data in the exclusion elements, including this base string.  The
caller of read_directory_recursive() is not supposed to free the
buffer it gave to push_exclude_per_directory() earlier, until it
returns.

The test case Bruce Stephens gave in the mailing list discussion
was simplified and added to the t3700 test.

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

core.excludesfile clean-up

There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable.  The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.

 * git-ls-files does not notice any of the "ignore" files by
   default, as it predates the standardized set of ignore files.
   The calling scripts established the convention to use
   .git/info/exclude, .gitignore, and later core.excludesfile.

 * git-add and git-status know about it because they call
   add_excludes_from_file() directly with their own notion of
   which standard set of ignore files to use.  This is just a
   stupid duplication of code that need to be updated every time
   the definition of the standard set of ignore files is
   changed.

 * git-read-tree takes --exclude-per-directory=<gitignore>,
   not because the flexibility was needed.  Again, this was
   because the option predates the standardization of the ignore
   files.

 * git-merge-recursive uses hardcoded per-directory .gitignore
   and nothing else.  git-clean (scripted version) does not
   honor core.* because its call to underlying ls-files does not
   know about it.  git-clean in C (parked in 'pu') doesn't either.

We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way.  I am somewhat reluctant to make such a change.

On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands.  I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.

This patch is the first step to untangle this mess.

The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().

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

Fix t9101 test failure caused by Subversion "auto-props"

If a user has an "auto-prop" in his/her ~/.subversion/config file for
automatically setting the svn:keyword Id property on all ".c" files
(a reasonably common configuration in the Subversion world) then one
of the "svn propset" operations in the very first test would become a
no-op, which in turn would make the next commit a no-op.

This then caused the 25th test ('test propget') to fail because it
expects a certain number of commits to have taken place but the actual
number of commits was off by one.

Björn Steinbrink identified the "auto-prop" feature as the cause
of the failure. This patch avoids it by passing the "--no-auto-prop"
flag to "svn import" when setting up the test repository, thus ensuring
that the "svn propset" operation is no longer a no-op, regardless of the
users' settings in their config.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-send-email: add charset header if we add encoded 'From'

We sometimes pick out the original rfc822 'From' header and
include it in the body of the message. If the original
author's name needs encoding, then we should specify that in
the content-type header.

If we already had a content-type header in the mail, then we
may need to re-encode. The logic is there to detect
this case, but it doesn't actually do the re-encoding.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix per-directory exclude handing for "git add"

In "dir_struct", each exclusion element in the exclusion stack records a
base string (pointer to the beginning with length) so that we can tell
where it came from, but this pointer is just pointing at the parameter
that is given by the caller to the push_exclude_per_directory()
function.

While read_directory_recursive() runs, calls to excluded() makes use
the data in the exclusion elements, including this base string.  The
caller of read_directory_recursive() is not supposed to free the
buffer it gave to push_exclude_per_directory() earlier, until it
returns.

The test case Bruce Stephens gave in the mailing list discussion
was simplified and added to the t3700 test.

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

Documentation: customize diff-options depending on particular command

Customize diff-options depending on particular command as follows,
mostly to make git-diff and git-format-patch manuals less confusing:

* git-format-patch:

  - Mark --patch-with-stat as being the default.

  - Change -p description so that it matches what it actually does and
    so that it doesn't refer to absent "section on generating
    patches".

* git-diff: mark -p as being the default.

* git-diff-index/git-diff-files/git-diff-tree: mark --raw as being
  the default.

Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-ls-files: add --exclude-standard

This provides a way for scripts to get at the new standard exclude
function.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Remove unreachable statements

Solaris Workshop Compiler found a few unreachable statements.

Signed-off-by: Guido Ostkamp <git@ostkamp.fastmail.fm>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refs.c: Remove unused get_ref_sha1()

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

core.excludesfile clean-up

There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable.  The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.

 * git-ls-files does not notice any of the "ignore" files by
   default, as it predates the standardized set of ignore files.
   The calling scripts established the convention to use
   .git/info/exclude, .gitignore, and later core.excludesfile.

 * git-add and git-status know about it because they call
   add_excludes_from_file() directly with their own notion of
   which standard set of ignore files to use.  This is just a
   stupid duplication of code that need to be updated every time
   the definition of the standard set of ignore files is
   changed.

 * git-read-tree takes --exclude-per-directory=<gitignore>,
   not because the flexibility was needed.  Again, this was
   because the option predates the standardization of the ignore
   files.

 * git-merge-recursive uses hardcoded per-directory .gitignore
   and nothing else.  git-clean (scripted version) does not
   honor core.* because its call to underlying ls-files does not
   know about it.  git-clean in C (parked in 'pu') doesn't either.

We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way.  I am somewhat reluctant to make such a change.

On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands.  I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.

This patch is the first step to untangle this mess.

The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().

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

Merge branch 'sp/fetch-fix'

* sp/fetch-fix:
  git-fetch: avoid local fetching from alternate (again)
  rev-list: Introduce --quiet to avoid /dev/null redirects
  run-command: Support sending stderr to /dev/null
  git-fetch: Always fetch tags if the object they reference exists

Merge branch 'bs/maint-commit-options'

* bs/maint-commit-options:
  git-commit: Add tests for invalid usage of -a/--interactive with paths
  git-commit.sh: Fix usage checks regarding paths given when they do not make sense

Merge branch 'rv/maint-index-commit'

* rv/maint-index-commit:
  Make GIT_INDEX_FILE apply to git-commit

Merge branch 'bs/maint-t7005'

* bs/maint-t7005:
  t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH

Merge branch 'jc/maint-add-sync-stat'

* jc/maint-add-sync-stat:
  t2200: test more cases of "add -u"
  git-add: make the entry stat-clean after re-adding the same contents
  ce_match_stat, run_diff_files: use symbolic constants for readability

Conflicts:

builtin-add.c

Merge branch 'mh/retag'

* mh/retag:
  Add tests for git tag
  Reuse previous annotation when overwriting a tag

Merge branch 'jc/stash-create'

* jc/stash-create:
  git-stash: Fix listing stashes
  git-merge: no reason to use cpio anymore
  Revert "rebase: allow starting from a dirty tree."
  rebase: allow starting from a dirty tree.
  stash: implement "stash create"

Merge branch 'bg/format-patch-N'

* bg/format-patch-N:
  Rearrange git-format-patch synopsis to improve clarity.
  format-patch: Test --[no-]numbered and format.numbered
  format-patch: Add configuration and off switch for --numbered

Merge branch 'np/progress'

* np/progress:
  nicer display of thin pack completion
  make display of total transferred fully accurate
  remove dead code from the csum-file interface
  git-fetch: be even quieter.
  make display of total transferred more accurate
  sideband.c: ESC is spelled '\033' not '\e' for portability.
  fix display overlap between remote and local progress

Merge branch 'js/rebase-detached'

* js/rebase-detached:
  rebase: fix "rebase --continue" breakage
  rebase: operate on a detached HEAD

Merge branch 'rs/pretty'

* rs/pretty:
  Fix preprocessor logic that determines the availablity of strchrnul().
  Simplify strchrnul() compat code
  --format=pretty: avoid calculating expensive expansions twice
  add strbuf_adddup()
  --pretty=format: parse commit message only once
  --pretty=format: on-demand format expansion
  Add strchrnul()

Merge branch 'rr/cvsexportcommit-w'

* rr/cvsexportcommit-w:
  cvsexportcommit: Add switch to specify CVS workdir

Merge branch 'gh/cvsimport-user'

* gh/cvsimport-user:
  git-cvsimport: fix handling of user name when it is not set in CVSROOT

user-manual: minor rewording for clarity.

Junio screwed up when applying the previous round of the patch;
rewording from "previous" to "old" does make the description
clearer.

Also revert the rewording from head to branch.  The description
is talking about the branch's tip commit and using the word head
is clearer.

Based on input from Sergei and Bruce.

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

Merge branch 'maint'

* maint:
  git-clean: honor core.excludesfile
  Documentation: Fix man page breakage with DocBook XSL v1.72
  git-remote.txt: fix typo
  core-tutorial.txt: Fix argument mistake in an example.
  replace reference to git-rm with git-reset in git-commit doc
  Grammar fixes for gitattributes documentation
  Don't allow fast-import tree delta chains to exceed maximum depth
  revert/cherry-pick: allow starting from dirty work tree.
  t/t3404: fix test for a bogus todo file.

Conflicts:

fast-import.c

Fix dependencies of parse-options test program

A stale test-parse-options can break t0040 otherwise.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual.txt: fix a few mistakes

Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-clean: honor core.excludesfile

git-clean did not honor core.excludesfile configuration
variable, although some other commands such as git-add and
git-status did.  Fix this inconsistency.

Original report and patch from Shun'ichi Fuji.  Rewritten by me
and bugs and tests are mine.

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

Documentation: Fix man page breakage with DocBook XSL v1.72

From version 1.72 it will replace all dots in roff requests with U+2302
("house" character), and add escaping in output for all instances of dot
that are not in roff requests. This caused the ".ft" hack forcing
monospace font in listingblocks to end up as "\&.ft" and being visible
in the resulting man page.

The fix adds a DOCBOOK_XSL_172 build variable that will disable the
hack. To allow this variable to be defined in config.mak it also moves
build variable handling below the inclusion of config.mak.

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Handle broken vsnprintf implementations in strbuf

Solaris 9's vsnprintf implementation returns -1 if we pass it a
buffer of length 0.  The only way to get it to give us the actual
length necessary for the formatted string is to grow the buffer
out to have at least 1 byte available in the strbuf and then ask
it to compute the length.

If the available space is 0 I'm growing it out by 64 to ensure
we will get an accurate length estimate from all implementations.
Some callers may need to grow the strbuf again but 64 should be a
reasonable enough initial growth.

We also no longer silently fail to append to the string when we are
faced with a broken vsnprintf implementation.  On Solaris 9 this
silent failure caused me to no longer be able to execute "git clone"
as we tried to exec the empty string rather than "git-clone".

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

git-remote.txt: fix typo

Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

core-tutorial.txt: Fix argument mistake in an example.

One of examples has wrong output given the arguments provided.
Fix arguments to match the output.

Fix a minor syntax mistake in another place.

Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

replace reference to git-rm with git-reset in git-commit doc

The message in git-commit suggesting to use 'git rm --cached'
to unstage is just plain wrong. It really should mention 'git reset'.

Suggested by Jan Hudec.

Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Grammar fixes for gitattributes documentation

Tweak the "filter" section of the gitattributes documentation to add
some
missing articles and improve some word choices without changing the
semantics of the section.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Don't allow fast-import tree delta chains to exceed maximum depth

Brian Downing noticed fast-import can produce tree depths of up
to 6,035 objects and even deeper.  Long delta chains can create
very small packfiles but cause problems during repacking as git
needs to unpack each tree to count the reachable blobs.

What's happening here is the active branch cache isn't big enough.
We're swapping out the branch and thus recycling the tree information
(struct tree_content) back into the free pool.  When we later reload
the tree we set the delta_depth to 0 but we kept the tree we just
reloaded as a delta base.

So if the tree we reloaded was already at the maximum depth we
wouldn't know it and make the new tree a delta.  Multiply the
number of times the branch cache has to swap out the tree times
max_depth (10) and you get the maximum delta depth of a tree created
by fast-import.  In Brian's case above the active branch cache had
to swap the branch out 603/604 times during this import to produce
a tree with a delta depth of 6035.

Acked-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Resurrect git-revert.sh example and add comment to builtin-revert.c

I had to scratch my head for quite some time figuring out why we
cannot optimize out write_tree() we do when --no-commit option
is given, whose purpose seem to be only to check if the index is
unmerged, with a simple loop over the active_cache[].

So add a comment to describe why the write_tree() is there, and
resurrect the last scripted version as a reference material in
contrib/example directory with others.

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

revert/cherry-pick: allow starting from dirty work tree.

There is no reason to forbid a dirty work tree when reverting or
cherry-picking a change, as long as the index is clean.

The scripted version used to allow it:

    case "$no_commit" in
    t)
     # We do not intend to commit immediately.  We just want to
     # merge the differences in.
     head=$(git-write-tree) ||
     die "Your index file is unmerged."
     ;;
    *)
     head=$(git-rev-parse --verify HEAD) ||
     die "You do not have a valid HEAD"
     files=$(git-diff-index --cached --name-only $head) || exit
     if [ "$files" ]; then
     die "Dirty index: cannot $me (dirty: $files)"
     fi
     ;;
    esac

but C rewrite tightened the check, probably by mistake.

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

t/t3404: fix test for a bogus todo file.

The test wants to see if there are still remaining tasks, but checked
a wrong file.

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

git-commit: Add tests for invalid usage of -a/--interactive with paths

git-commit was/is broken in that it accepts paths together with -a or
--interactive, which it shouldn't. There tests check those usage errors.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix preprocessor logic that determines the availablity of strchrnul().

Apart from the error in the condition (&& should actually be ||), the
construct

    #if !defined(A) || !A

leads to a syntax error in the C preprocessor if A is indeed not defined.

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

git-clean: Fix error message if clean.requireForce is not set.

It was distracting to see this error message:

     clean.requireForce set and -n or -f not given; refusing to clean

even though clean.requireForce was not set at all. This patch distinguishes
the cases and gives a different message depending on whether the
configuration variable is not set or set to true.

While we are here, we also divert the error messages to stderr.

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

rebase: fix "rebase --continue" breakage

The --skip case was handled properly when rebasing without --merge,
but the --continue case was not.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: support for funky branch and project names over HTTP(S)

SVN requires that paths be URI-escaped for HTTP(S) repositories.
file:// and svn:// repositories do not need these rules.

Additionally, accessing individual paths inside repositories
(check_path() and get_log() do NOT require escapes to function
and in fact it breaks things).

Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: Fix references to deprecated commands

... by changing git-tar-tree reference to git-archive and removing
seemingly unrelevant footnote about git-ssh-{fetch,upload}.

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  for-each-ref: fix off by one read.
  git-branch: remove mention of non-existent '-b' option
  git-svn: prevent dcommitting if the index is dirty.
  Fix memory leak in traverse_commit_list

Merge branch 'sp/maint-plug-traverse-commit-list-leak' into maint

* sp/maint-plug-traverse-commit-list-leak:
  Fix memory leak in traverse_commit_list

for-each-ref: fix off by one read.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-branch: remove mention of non-existent '-b' option

This looks like a cut and paste error from the git-checkout
explanation of --no-track.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: prevent dcommitting if the index is dirty.

dcommit uses rebase to sync the history with what has just been pushed to
SVN.  Trying to dcommit with a dirty index is troublesome for rebase, so now
the user will get an error message if he attempts to dcommit with a dirty
index.

Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t2200: test more cases of "add -u"

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

git-fetch: avoid local fetching from alternate (again)

Back in e3c6f240fd9c5bdeb33f2d47adc859f37935e2df Junio taught
git-fetch to avoid copying objects when we are fetching from
a repository that is already registered as an alternate object
database.  In such a case there is no reason to copy any objects
as we can already obtain them through the alternate.

However we need to ensure the objects are all reachable, so we
run `git rev-list --objects $theirs --not --all` to verify this.
If any object is missing or unreadable then we need to fetch/copy
the objects from the remote.  When a missing object is detected
the git-rev-list process will exit with a non-zero exit status,
making this condition quite easy to detect.

Although git-fetch is currently a builtin (and so is rev-list)
we cannot invoke the traverse_objects() API at this point in the
transport code.  The object walker within traverse_objects() calls
die() as soon as it finds an object it cannot read.  If that happens
we want to resume the fetch process by calling do_fetch_pack().
To get around this we spawn git-rev-list into a background process
to prevent a die() from killing the foreground fetch process,
thus allowing the fetch process to resume into do_fetch_pack()
if copying is necessary.

We aren't interested in the output of rev-list (a list of SHA-1
object names that are reachable) or its errors (a "spurious" error
about an object not being found as we need to copy it) so we redirect
both stdout and stderr to /dev/null.

We run this git-rev-list based check before any fetch as we may
already have the necessary objects local from a prior fetch.  If we
don't then its very likely the first $theirs object listed on the
command line won't exist locally and git-rev-list will die very
quickly, allowing us to start the network transfer.  This test even
on remote URLs may save bandwidth if someone runs `git pull origin`,
sees a merge conflict, resets out, then redoes the same pull just
a short time later.  If the remote hasn't changed between the two
pulls and the local repository hasn't had git-gc run in it then
there is probably no need to perform network transfer as all of
the objects are local.

Documentation for the new quickfetch function was suggested and
written by Junio, based on his original comment in git-fetch.sh.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

rev-list: Introduce --quiet to avoid /dev/null redirects

Some uses of git-rev-list are to run it with --objects to see if
a range of objects between two or more commits is fully connected
or not.  In such a case the caller doesn't care about the actual
object names or hash hints so formatting this data only for it to
be dumped to /dev/null by a redirect is a waste of CPU time.  If
all the caller needs is the exit status then --quiet can be used
to bypass the commit and object formatting.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

run-command: Support sending stderr to /dev/null

Some callers may wish to redirect stderr to /dev/null in some
contexts, such as if they are executing a command only to get
the exit status and don't want users to see whatever output it
may produce as a side-effect of computing that exit status.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-fetch: Always fetch tags if the object they reference exists

Previously git-fetch.sh used `git cat-file -t` to determine if an
object referenced by a tag exists, and if so fetch that tag locally.
This was subtly broken during the port to C based builtin-fetch as
lookup_object() only works to locate an object if it was previously
accessed by the transport.  Not all transports will access all
objects in this way, so tags were not always being fetched.

The rsync transport never loads objects into the internal object
table so automated tag following didn't work if rsync was used.
Automated tag following also didn't work on the native transport
if the new tag was behind the common point(s) negotiated between
the two ends of the connection as the tag's referrant would not
be loaded into the internal object table.  Further the automated
tag following was broken with the HTTP commit walker if the new
tag's referrant was behind an existing ref, as the walker would
stop before loading the tag's referrant into the object table.

Switching to has_sha1_file() restores the original behavior from
the shell script by checking if the object exists in the ODB,
without relying on the state left behind by a transport.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'sp/maint-plug-traverse-commit-list-leak' into sp/fetch-fix

* sp/maint-plug-traverse-commit-list-leak:
  Fix memory leak in traverse_commit_list

t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH

The git wrapper executable always prepends the GIT_EXEC_PATH build
variable to the current PATH, so prepending "." to the PATH is not
enough to give precedence to the fake vi executable.

The --exec-path option allows to prepend a directory to PATH even before
GIT_EXEC_PATH (which is added anyway), so we can use that instead.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Make GIT_INDEX_FILE apply to git-commit

Currently, when committing, git-commit ignore the value of
GIT_INDEX_FILE, and always use $GIT_DIR/index. This patch
fix it.

Signed-off-by: Rémi Vanicat <vanicat@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'js/upload-pack'

* js/upload-pack:
  upload-pack: Use finish_{command,async}() instead of waitpid().

Merge branch 'js/reset'

* js/reset:
  builtin-reset: avoid forking "update-index --refresh"
  builtin-reset: do not call "ls-files --unmerged"

Merge branch 'js/parseopt-abbrev-fix'

* js/parseopt-abbrev-fix:
  parse-options: abbreviation engine fix.

Merge branch 'maint'

* maint:
  fix index-pack with packs >4GB containing deltas on 32-bit machines
  git-hash-object should honor config variables
  gitweb: correct month in date display for atom feeds

push: teach push to pass --verbose option to transport layer

A --verbose option to push should also be passed to the
transport layer, i.e. git-send-pack, git-http-push.

git push is modified to do so.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: mention --verbose option in documentation

Before this commit, only '-v' was documented.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Simplify strchrnul() compat code

strchrnul() was introduced in glibc in April 1999 and included in
glibc-2.1. Checking for that version means the majority of all git
users would get to use the optimized version in glibc. Of the
remaining few some might get to use a slightly slower version
than necessary but probably not slower than what we have today.

Unfortunately, __GLIBC_PREREQ() macro was not available in glibc 2.1.1
which was short lived but already supported strchrnul().  Odd minority
users of that library needs to live with our compatibility inline version.

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

fix index-pack with packs >4GB containing deltas on 32-bit machines

This probably hasn't been properly tested before.  Here's a script to
create a 8GB repo with the necessary characteristics (copy the
test-genrandom executable from the Git build tree to /tmp first):

-----
#!/bin/bash

git init
git config core.compression 0

# create big objects with no deltas
for i in $(seq -w 1 2 63)
do
echo $i
/tmp/test-genrandom $i 268435456 > file_$i
git add file_$i
rm file_$i
echo "file_$i -delta" >> .gitattributes
done

# create "deltifiable" objects in between big objects
for i in $(seq -w 2 2 64)
do
echo "$i $i $i" >> grow
cp grow file_$i
git add file_$i
rm file_$i
done
rm grow

# create a pack with them
git commit -q -m "commit of big objects interlaced with small deltas"
git repack -a -d
-----

Then clone this repo over the Git protocol.

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

git-hash-object should honor config variables

... such as core.compression.

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

--format=pretty: avoid calculating expensive expansions twice

As Jeff King remarked, format strings with duplicate placeholders can
be slow to expand, because each instance is calculated anew.

This patch makes use of the fact that format_commit_message() and its
helper functions only ever add stuff to the end of the strbuf.  For
certain expensive placeholders, store the offset and length of their
expansion with the strbuf at the first occurrence.  Later they
expansion result can simply be copied from there -- no malloc() or
strdup() required.

These certain placeholders are the abbreviated commit, tree and
parent hashes, as the search for a unique abbreviated hash is quite
costly.  Here are the times for next (best of three runs):

$ time git log --pretty=format:%h >/dev/null

real    0m0.611s
user    0m0.404s
sys     0m0.204s

$ time git log --pretty=format:%h%h%h%h >/dev/null

real    0m1.206s
user    0m0.744s
sys     0m0.452s

And here those with this patch (and the previous two); the speedup
of the single placeholder case is just noise:

$ time git log --pretty=format:%h >/dev/null

real    0m0.608s
user    0m0.416s
sys     0m0.192s

$ time git log --pretty=format:%h%h%h%h >/dev/null

real    0m0.639s
user    0m0.488s
sys     0m0.140s

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

add strbuf_adddup()

Add a new function, strbuf_adddup(), that appends a duplicate of a
part of a struct strbuf to end of the latter.

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

--pretty=format: parse commit message only once

As Jeff King pointed out, some placeholder expansions are related to
each other: the steps to calculate one go most of the way towards
calculating the other, too.

This patch makes format_commit_message() parse the commit message
only once, remembering the position of each item.  This speeds up
handling of format strings containing multiple placeholders from the
set %s, %a*, %c*, %e, %b.

Here are the timings for the git version in next.  The first one is
to estimate the overhead of the caching, the second one is taken
from http://svn.tue.mpg.de/tentakel/trunk/tentakel/Makefile as an
example of a format string found in the wild.  The times are the
fastest of three consecutive runs in each case:

$ time git log --pretty=format:%e >/dev/null

real    0m0.381s
user    0m0.340s
sys     0m0.024s

$ time git log --pretty=format:"* %cd %cn%n%n%s%n%b" >/dev/null

real    0m0.623s
user    0m0.556s
sys     0m0.052s

And here the times with this patch:

$ time git log --pretty=format:%e >/dev/null

real    0m0.385s
user    0m0.332s
sys     0m0.040s

$ time git log --pretty=format:"* %cd %cn%n%n%s%n%b" >/dev/null

real    0m0.563s
user    0m0.504s
sys     0m0.048s

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

gitweb: correct month in date display for atom feeds

Signed-off-by: Vincent Zanotti <vincent.zanotti@m4x.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-lib.sh: move error line after error() declaration

This patch removes a spurious "command not found" error
and actually makes the "Test script did not set test_description."
string follow the command line option "--no-color".

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

for-each-ref: fix setup of option-parsing for --sort

The option value for --sort is already a pointer to a pointer to struct
ref_sort, so just use it.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  print warning/error/fatal messages in one shot

core-tutorial.txt: Fix git-show-branch example and its description

Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix memory leak in traverse_commit_list

If we were listing objects too then the objects were buffered in an
array only reachable from a stack allocated structure.  When this
function returns that array would be leaked as nobody would have
a reference to it anymore.

Historically this hasn't been a problem as the primary user of
traverse_commit_list() (the noble git-rev-list) would terminate
as soon as the function was finished, thus allowing the operating
system to cleanup memory.  However we have been leaking this data
in git-pack-objects ever since that program learned how to run the
revision listing internally, rather than relying on reading object
names from git-rev-list.

To better facilitate reuse of traverse_commit_list during other
builtin tools (such as git-fetch) we shouldn't leak temporary memory
like this and instead we need to clean up properly after ourselves.

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

git-commit: a bit more tests

Add tests for -s (sign-off) and multiple -m options

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

git-add: make the entry stat-clean after re-adding the same contents

Earlier in commit 0781b8a9b2fe760fc4ed519a3a26e4b9bd6ccffe
(add_file_to_index: skip rehashing if the cached stat already
matches), add_file_to_index() were taught not to re-add the path
if it already matches the index.

The change meant well, but was not executed quite right.  It
used ie_modified() to see if the file on the work tree is really
different from the index, and skipped adding the contents if the
function says "not modified".

This was wrong.  There are three possible comparison results
between the index and the file in the work tree:

 - with lstat(2) we _know_ they are different.  E.g. if the
   length or the owner in the cached stat information is
   different from the length we just obtained from lstat(2), we
   can tell the file is modified without looking at the actual
   contents.

 - with lstat(2) we _know_ they are the same.  The same length,
   the same owner, the same everything (but this has a twist, as
   described below).

 - we cannot tell from lstat(2) information alone and need to go
   to the filesystem to actually compare.

The last case arises from what we call 'racy git' situation,
that can be caused with this sequence:

    $ echo hello >file
    $ git add file
    $ echo aeiou >file ;# the same length

If the second "echo" is done within the same filesystem
timestamp granularity as the first "echo", then the timestamp
recorded by "git add" and the timestamp we get from lstat(2)
will be the same, and we can mistakenly say the file is not
modified.  The path is called 'racily clean'.  We need to
reliably detect racily clean paths are in fact modified.

To solve this problem, when we write out the index, we mark the
index entry that has the same timestamp as the index file itself
(that is the time from the point of view of the filesystem) to
tell any later code that does the lstat(2) comparison not to
trust the cached stat info, and ie_modified() then actually goes
to the filesystem to compare the contents for such a path.

That's all good, but it should not be used for this "git add"
optimization, as the goal of "git add" is to actually update the
path in the index and make it stat-clean.  With the false
optimization, we did _not_ cause any data loss (after all, what
we failed to do was only to update the cached stat information),
but it made the following sequence leave the file stat dirty:

    $ echo hello >file
    $ git add file
    $ echo hello >file ;# the same contents
    $ git add file

The solution is not to use ie_modified() which goes to the
filesystem to see if it is really clean, but instead use
ie_match_stat() with "assume racily clean paths are dirty"
option, to force re-adding of such a path.

There was another problem with "git add -u".  The codepath
shares the same issue when adding the paths that are found to be
modified, but in addition, it asked "git diff-files" machinery
run_diff_files() function (which is "git diff-files") to list
the paths that are modified.  But "git diff-files" machinery
uses the same ie_modified() call so that it does not report
racily clean _and_ actually clean paths as modified, which is
not what we want.

The patch allows the callers of run_diff_files() to pass the
same "assume racily clean paths are dirty" option, and makes
"git-add -u" codepath to use that option, to discover and re-add
racily clean _and_ actually clean paths.

We could further optimize on top of this patch to differentiate
the case where the path really needs re-adding (i.e. the content
of the racily clean entry was indeed different) and the case
where only the cached stat information needs to be refreshed
(i.e. the racily clean entry was actually clean), but I do not
think it is worth it.

This patch applies to maint and all the way up.

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

ce_match_stat, run_diff_files: use symbolic constants for readability

ce_match_stat() can be told:

 (1) to ignore CE_VALID bit (used under "assume unchanged" mode)
     and perform the stat comparison anyway;

 (2) not to perform the contents comparison for racily clean
     entries and report mismatch of cached stat information;

using its "option" parameter.  Give them symbolic constants.

Similarly, run_diff_files() can be told not to report anything
on removed paths.  Also give it a symbolic constant for that.

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

print warning/error/fatal messages in one shot

Not doing so is likely to create a messed up display when sent over the
sideband protocol.

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

builtin-blame: set up the work_tree before the first file access

We check in cmd_blame() if the specified path is there, but we
failed to set up the working tree before that.

While at it, make setup_work_tree() just return if it was run
before.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add a howto document about corrupted blob recovery

Extracted from a post by Linus on the mailing list.

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

Documentation: remove documentation for removed tools.

Old commit walkers other than http/curl transport have been removed
for some time now.  Remove their documents.

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

Make check-docs target detect removed commands

The maintainer should remember running "make check-docs" from
time to time.

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

Documentation: lost-found is now deprecated.

This makes it possible to mark commands that are deprecated in the
command list of the primary manual page git(7), and uses it to
mark "git lost-found" and "git tar-tree" as deprecated.

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

rebase: operate on a detached HEAD

The interactive version of rebase does all the operations on a detached
HEAD, so that after a successful rebase, <branch>@{1} is the pre-rebase
state.  The reflogs of "HEAD" still show all the actions in detail.

This teaches the non-interactive version to do the same.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

--pretty=format: on-demand format expansion

Some of the --pretty=format placeholders expansions are expensive to
calculate.  This is made worse by the current code's use of
interpolate(), which requires _all_ placeholders are to be prepared
up front.

One way to speed this up is to check which placeholders are present
in the format string and to prepare only the expansions that are
needed.  That still leaves the allocation overhead of interpolate().

Another way is to use a callback based approach together with the
strbuf library to keep allocations to a minimum and avoid string
copies.  That's what this patch does.  It introduces a new strbuf
function, strbuf_expand().

The function takes a format string, list of placeholder strings,
a user supplied function 'fn', and an opaque pointer 'context'
to tell 'fn' what thingy to operate on.

The function 'fn' is expected to accept a strbuf, a parsed
placeholder string and the 'context' pointer, and append the
interpolated value for the 'context' thingy, according to the
format specified by the placeholder.

Thanks to Pierre Habouzit for his suggestion to use strchrnul() and
the code surrounding its callsite.  And thanks to Junio for most of
this commit message. :)

Here my measurements of most of Paul Mackerras' test cases that
highlighted the performance problem (best of three runs):

(master)
$ time git log --pretty=oneline >/dev/null

real    0m0.390s
user    0m0.340s
sys     0m0.040s

(master)
$ time git log --pretty=raw >/dev/null

real    0m0.434s
user    0m0.408s
sys     0m0.016s

(master)
$ time git log --pretty="format:%H {%P} %ct" >/dev/null

real    0m1.347s
user    0m0.080s
sys     0m1.256s

(interp_find_active -- Dscho)
$ time ./git log --pretty="format:%H {%P} %ct" >/dev/null

real    0m0.694s
user    0m0.020s
sys     0m0.672s

(strbuf_expand -- this patch)
$ time ./git log --pretty="format:%H {%P} %ct" >/dev/null

real    0m0.395s
user    0m0.352s
sys     0m0.028s

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

Add strchrnul()

As suggested by Pierre Habouzit, add strchrnul().  It's a useful GNU
extension and can simplify string parser code.  There are several
places in git that can be converted to strchrnul(); as a trivial
example, this patch introduces its usage to builtin-fetch--tool.c.

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

git-cvsimport: fix handling of user name when it is not set in CVSROOT

The cvs programs do not default to "anonymous" as the user name, but use the
currently logged in user.  This patch more closely matches the cvs behavior.

Signed-off-by: Gordon Hopper <g.hopper@computer.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes for 1.5.4

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

Merge branch 'maint'

* maint:
  Start preparing for 1.5.3.6
  git-send-email: Change the prompt for the subject of the initial message.
  SubmittingPatches: improve the 'Patch:' section of the checklist
  instaweb: Minor cleanups and fixes for potential problems
  stop t1400 hiding errors in tests
  Makefile: add missing dependency on wt-status.h
  refresh_index_quietly(): express "optional" nature of index writing better
  Fix sed string regex escaping in module_name.
  Avoid a few unportable, needlessly nested "...`...".
  git-mailsplit: with maildirs not only process cur/, but also new/

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

git-bisect.sh: Fix sed script to work with AIX and BSD sed.

\n is not portable in a s/// replacement string, only
in the regex part.  backslash-newline helps.

Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start preparing for 1.5.3.6

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

git-send-email: Change the prompt for the subject of the initial message.

I never understood what this prompt was asking for until I read the actual
source code.  I think this wording is much more understandable.

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

SubmittingPatches: improve the 'Patch:' section of the checklist

There were 2 items "send patch to..." but having different set of
addresses to send patch to. Merge them together and move the resulting
item to the end of checklist.

Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>