tokkee.org

Merge branch 'cc/maint-bisect-paths'

* cc/maint-bisect-paths:
  bisect: error out when passing bad path parameters

bisect: error out when passing bad path parameters

As reported by Mark Lodato, "git bisect", when it was started with
path parameters that match no commit was kind of working without
taking account of path parameters and was reporting something like:

Bisecting: -1 revisions left to test after this (roughly 0 steps)

It is more correct and safer to just error out in this case, before
displaying the revisions left, so this patch does just that.

Note that this bug is very old, it exists at least since v1.5.5.
And it is possible to detect that case earlier in the bisect
algorithm, but it is not clear that it would be an improvement to
error out earlier, on the contrary it may change the behavior of
"git rev-list --bisect-all" for example, which is currently correct.

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

Merge branch 'maint'

* maint:
  Git 1.7.0.1
  Remove reference to GREP_COLORS from documentation
  sha1_name: fix segfault caused by invalid index access

Git 1.7.0.1

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

Remove reference to GREP_COLORS from documentation

There is no longer support for external grep, as per bbc09c2 (grep: rip
out support for external grep, 2010-01-12), so remove the reference to it
from the documentation.

Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-am: Add tests for `--keep-cr`, `--no-keep-cr` and `am.keepcr`

Add tests for git-am using files with DOS line endings for various
combinations of `--keep-cr`, `--no-keep-cr` and `am.keepcr`.

Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-am: Add am.keepcr and --no-keep-cr to override it

This patch adds the configuration `am.keepcr` for git-am. It also adds
`--no-keep-cr` parameter for git-am to give the possibility to
override configuration from command line.

Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-am: Add command line parameter `--keep-cr` passing it to git-mailsplit

c2ca1d7 (Allow mailsplit (and hence git-am) to handle mails with CRLF
line-endings, 2009-08-04) fixed "git mailsplit" to help people with
MUA whose output from save-as command uses CRLF as line terminators by
stripping CR at the end of lines.

However, when you know you are feeding output from "git format-patch"
directly to "git am", and especially when your contents have CR at the
end of line, such stripping is undesirable.  To help such a use case,
teach --keep-cr option to "git am" and pass that to "git mailinfo".

Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

documentation: 'git-mailsplit --keep-cr' is not hidden anymore

So far this was an internal mechanism for rebase, but we will be exposing
it to the end users.

Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: clarify definition of TEST_OBJS

The definition of TEST_OBJS in commit daa99a91 (Makefile: make sure
test helpers are rebuilt when headers change, 2010-01-26) moved a use
of $X to before the platform-specific section where it gets defined.
There are at least two ways to fix that:

 - Change the definition of TEST_OBJS to use the = delayed
   evaluation operator.  This way, one need not worry about $(X)
   needing to be defined before TEST_OBJS is set.

 - Move the definition of TEST_OBJS to below the definition of $X.

Carry out the second.  The later site of definition makes the code more
readable, since now a reader only has to look down one line to see what
TEST_OBJS is meant to be used for.

Oddly enough, with or without this change the behavior of the Makefile
is the same.  Since TEST_PROGRAMS is defined with delayed evaluation,
the value of

 TEST_OBJS := $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))

is independent of the value of $X when it is evaluated: the $X in the
pattern and the $X in $(TEST_PROGRAMS) will simply always cancel out.
Make sure $X has the expected expansion anyway to make the code and
the reader’s sanity more robust in the face of future changes.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-push: add tests for git push --porcelain

Verify that the output format is correct for successful, rejected, and
flagrantly erroneous pushes.

Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-push: make git push --porcelain print "Done"

The script calling git push --porcelain --dry-run can see clearly from the
output if an update was rejected.  However, it will probably need to distinguish
this condition from the push failing for other reasons, such as the remote not
being reachable.

This patch modifies git push --porcelain to print "Done" after the rest of its
output unless any errors have occurred.  For the purpose of the "Done" line,
knowing a ref will be rejected in a --dry-run does not count as an error.
Actual rejections in non --dry-run pushes do count as errors.

Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Acked-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-push: send "To <remoteurl>" messages to the standard output in --porcelain mode

git-push prints the line "To <remoteurl>" before above each of the ref status
lines.  In --porcelain mode, these "To <remoteurl>" lines go to the standard
error, but the ref status lines go to the standard output.  This makes it
difficult for the process reading standard output to know which ref status lines
correspond to which remote.  This patch sends the "To <remoteurl>" lines to the
the standard output instead.

Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-push: fix an advice message so it goes to stderr

These sort of messages typically go to the standard error.

Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1_name: fix segfault caused by invalid index access

The code to see if user input "git show :path" makes sense tried to access
the index without properly checking the array bound.

Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

reflog: honor gc.reflogexpire=never

Previously, if gc.reflogexpire or gc.reflogexpire were set to "never"
or "false", the builtin default values were used instead.

Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

prune: honor --expire=never

Previously, prune treated an expiration time of 0 to mean that no
expire argument was supplied, and everything should be pruned.  As a
result, "prune --expire=never" would prune all unreachable objects,
regardless of their timestamp.

prune can be called with --expire=never automatically by gc, when the
gc.pruneExpire configuration is set to "never".

Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git svn: delay importing SVN::Base until it is needed

Importing functions from a .dll into Git for Windows' perl is pretty slow,
so let's avoid importing if it is not necessary.

This seems particularly slow in virtualized enviroments. Before this
change (on my machine):

$ time perl /libexec/git-core/git-svn rebase
Current branch master is up to date.

real 2m56.750s
user 0m3.129s
sys 2m39.232s

Afterwards:

$ time perl /libexec/git-core/git-svn rebase
Current branch master is up to date.

real 0m33.407s
user 0m1.409s
sys 0m23.054s

git svn rebase -n goes from 3m7.046s to 0m10.312s.

Signed-off-by: Josh Robb <josh_robb@fastmail.fm>
Acked-by: Eric Wong <normalperson@yhbt.net>

git-svn: Fix discarding of extra parents from svn:mergeinfo

If parent J is an ancestor of parent I, then parent J should be
discarded, not I.

Note that J is an ancestor of I if and only if rev-list I..J is emtpy,
which is what we are testing here.

Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

t9151: Add two new svn:mergeinfo test cases

When svn:mergeinfo contains two new parents in a specific order and
one is ancestor of the other, it is possible that git-svn discards the
wrong one. The first test case ("commit made to merged branch is
reachable from the merge") proves this.

The second test case ("merging two branches in one commit is detected
correctly") is just for completeness, since there was no test for
merging two (feature) branches to trunk in one commit.

Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

t9151: Fix a few commits in the SVN dump

A few "svn cp" commands and commit commands were executed in incorrect
order. Therefore some of the desired commits were missing and some
were committed with wrong revision number in the commit message. This
made it hard to compare the produced git repository with the SVN
repository.

The dump file is updated too, but only the relevant parts and with
hand-edited timestamps to make history linear.

Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>

Merge branch 'maint'

* maint:
  t3301-notes: insert a shbang line in ./fake_editor.sh

Merge branch 'maint-1.6.6' into maint

* maint-1.6.6:
  t3301-notes: insert a shbang line in ./fake_editor.sh

t/t0001-init.sh: add test for 'init with init.templatedir set'

Requires a small change to wrap-for-bin.sh in order to work.

Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

init: having keywords without value is not a global error.

We may later add a new configuration variable in "init" section that takes
a boolean value.  Erroring out at the beginning of the config parser makes
life harder for later enhancement.

The existing configuration variable is parsed by git_config_pathname()
that checks and rejects init.templatedir that is unset without this extra
check.  Remove it.

Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

grep docs: document --no-index option

Also clarify --cached and <tree>.

Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

grep docs: --cached and <tree>... are incompatible

In the synopsis for git-grep(1), show that --cached and <tree>... cannot
be used together.

Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

grep docs: use AsciiDoc literals consistently

The convention for this particular page is to use AsciiDoc literal
strings only for options (`-x` or `--long`), but not for definition list
terms and not for <meta-vars>.

Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

grep docs: pluralize "Example" section

Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Windows: redirect f[re]open("/dev/null") to f[re]open("nul")

On Windows, the equivalent of "/dev/null" is "nul". This implements
compatibility wrappers around fopen() and freopen() that check for this
particular file name.

The new tests exercise code paths where this is relevant.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3301-notes: insert a shbang line in ./fake_editor.sh

This is required on Windows because git-notes is now a built-in
rather than a shell script.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix gitmkdtemp: correct test for mktemp() return value

In gitmkdtemp, the return value of mktemp is not tested correctly.
mktemp() always returns its 'template' argument, even upon failure.
An error is signalled by making the template an empty string.

Signed-off-by: Filippo Negroni <fnegroni@flexerasoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

notes: fix malformed tree entry

The mode bits for entries in a tree object should be an octal number
with minimum number of digits.  Do not pad it with 0 to the left.

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

builtin-notes: Minor (mostly parse_options-related) fixes

Use PARSE_OPT_NONEG to disallow --no-<option> for message, file,
reedit-message and reuse-message. for which --no-<option> does not make
sense.  This also simplifies the code in the option-handling callbacks.

Also, use strbuf_addch(... '\n') instead of strbuf_addstr(... "\n") in
couple of places.

Finally, improve the short-help by dividing the options into two
OPT_GROUPs.

Suggested-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Acked-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack-objects documentation: Fix --honor-pack-keep as well.

Signed-off-by: Nelson Elhage <nelhage@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

is_submodule_modified(): clear environment properly

Rather than only clearing GIT_INDEX_FILE, take the list of environment
variables to clear from local_repo_env, appending the settings for
GIT_DIR and GIT_WORK_TREE.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodules: ensure clean environment when operating in a submodule

git-submodule used to take care of clearing GIT_DIR whenever it operated
on a submodule index or configuration, but forgot to unset GIT_WORK_TREE
or other repo-local variables. This would lead to failures e.g. when
GIT_WORK_TREE was set.

This only happened in very unusual contexts such as operating on the
main worktree from outside of it, but since "git-gui: set GIT_DIR and
GIT_WORK_TREE after setup" (a9fa11fe5bd5978bb) such failures could also
be provoked by invoking an external tool such as "git submodule update"
from the Git Gui in a standard setup.

Solve by using the newly introduced clear_local_git_env() shell function
to ensure that all repo-local environment variables are unset.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

shell setup: clear_local_git_env() function

Introduce an auxiliary function to clear all repo-local environment
variables. This should be invoked by any shell script that switches
repository during execution, to ensure that the environment is clean
and that things such as the git dir and worktree are set up correctly.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-parse: --local-env-vars option

This prints the list of repo-local environment variables.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Refactor list of of repo-local env vars

Move the list of GIT_* environment variables that are local to a
repository into a static list in environment.c, as it is also
useful elsewhere. Also add the missing GIT_CONFIG variable to the
list.

Make it easy to use the list both by NULL-termination and by size;
the latter (excluding the terminating NULL) is stored in the
local_repo_env_size define.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack-objects documentation: reword "objects that appear in the standard input"

These were written back when we always read objects from the standard
input.  These days --revs and its friends can feed only the start and
end points and have the command internally enumerate the objects.

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

Merge branch 'maint'

* maint:
  commit: quote the user name in the example

commit: quote the user name in the example

If the user runs

 git config --global user.name Your Name

as suggested, user.name will be set to "Your".  With this patch, the
suggested command will be

 git config --global user.name "Your Name"

which will set user.name to "Your Name" and hopefully help users avoid
the former mistake.

Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ml/maint-grep-doc' into maint

* ml/maint-grep-doc:
  grep documentation: clarify what files match

shortlog: warn the user when there is no input

A simple "git shortlog" outside of a git repository stalls
waiting for an input. Check if that's the case by testing with
isatty() before read_from_stdin(), and warn the user like
"git commit" does in a similar case.

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

fetch --all/--multiple: keep all the fetched branch information

Since "git fetch" learned "--all" and "--multiple" options, it has become
tempting for users to say "git pull --all".  Even though it may fetch from
remotes that do not need to be fetched from for merging with the current
branch, it is handy.

"git fetch" however clears the list of fetched branches every time it
contacts a different remote.  Unless the current branch is configured to
merge with a branch from a remote that happens to be the last in the list
of remotes that are contacted, "git pull" that fetches from multiple
remotes will not be able to find the branch it should be merging with.

Make "fetch" clear FETCH_HEAD (unless --append is given) and then append
the list of branches fetched to it (even when --append is not given).  That
way, "pull" will be able to find the data for the branch being merged in
FETCH_HEAD no matter where the remote appears in the list of remotes to be
contacted by "git fetch".

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

push: fix segfault for odd config

If you have a branch.$X.merge config option, but no branch.$X.remote, and
your configuration tries to push tracking branches, git will segfault.

The problem is that even though branch->merge_nr is 1, you don't actually
have an upstream since there is no remote.  Other callsites generally
check explicitly that branch->merge is not NULL, so let's do that here,
too.

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

builtin-fetch --all/--multi: propagate options correctly

When running a subfetch, the code propagated some options but not others.
Propagate --force, --update-head-ok and --keep options as well.

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

t5521: fix and modernize

All of these tests were bogus, as they created new directory and tried to
run "git pull" without even running "git init" in there.  They were mucking
with the repository in $TEST_DIRECTORY.

While fixing it, modernize the style not to chdir around outside of
subshell.  Otherwise a failed test will take us to an unexpected directory
and we need to chdir back to the test directory in each test, which is
ugly and error prone.

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

transport: update flags to be in running order

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch and pull: learn --progress

Note that in the documentation for git-pull, documentation for the
--progress option is displayed under the "Options related to fetching"
subtitle via fetch-options.txt.

Also, update the documentation of the -q/--quiet option for git-pull to
mention its effect on progress reporting during fetching.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: learn --progress

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

transport->progress: use flag authoritatively

Set transport->progress in transport.c::transport_set_verbosity() after
checking for the appropriate conditions (eg. --progress, isatty(2)),
and thereafter use it without having to check again.

The rules used are as follows (processing aborts when a rule is
satisfied):

  1. Report progress, if force_progress is 1 (ie. --progress).
  2. Don't report progress, if verbosity < 0 (ie. -q/--quiet).
  3. Report progress if isatty(2) is 1.

This changes progress reporting behaviour such that if both --progress
and --quiet are specified, progress is reported.

In two areas, the logic to determine whether to *not* show progress is
changed to simply use the negation of transport->progress. This changes
behaviour in some ways (see previous paragraph for details).

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

clone: support multiple levels of verbosity

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: support multiple levels of verbosity

Remove the flags TRANSPORT_PUSH_QUIET and TRANSPORT_PUSH_VERBOSE; use
transport->verbose instead to determine verbosity for pushing.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: refactor verbosity option handling into transport.[ch]

transport_set_verbosity() is now provided to transport users.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/git-push: put --quiet before --verbose

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/git-pull: put verbosity options before merge/fetch ones

After 3f7a9b5 (Documentation/git-pull.txt: Add subtitles above included
option files, Thu Oct 22 2009), the -q/-v options were mentioned only
for the merge options section, giving the impression that git-fetch did
not take those arguments.

Follow 90e4311 (git-pull: do not mention --quiet and --verbose twice,
Mon Sep 7 2009) and hide -q/-v for merge options, while mentioning -q/-v
before the merge- and fetch-specific options.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/git-clone: mention progress in -v

After 5a518ad (clone: use --progress to force progress reporting),
-v/--verbose did not affect whether progress status was reported to
stderr, and users accustomed to using -v to do so since 21188b1
(Implement git clone -v) may be confused.

Mitigate such risks by stating -v does not affect progress in the
documentation.

Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bash: completion for gitk aliases

gitk aliases either start with "!gitk", or look something like "!sh -c
FOO=bar gitk", IOW they contain the "gitk" word.  With this patch the
completion script will recognize these cases and will offer gitk's
options.

Just like the earlier change improving on aliased command recognition,
this change can also be fooled easily by some complex aliases, but
users of such aliases could remedy it with custom completion
functions.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bash: support user-supplied completion scripts for aliases

Shell command aliases can get rather complex, and the completion
script can not always determine correctly the git command invoked by
such an alias.  For such cases users might want to provide custom
completion scripts the same way like for their custom commands made
possible by the previous patch.

The current completion script does not allow this, because if it
encounters an alias, then it will unconditionally perform completion
for the aliased git command (in case it can determine the aliased git
command, of course).  With this patch the completion script will first
search for a completion function for the command given on the command
line, be it a git command, a custom git command of the user, or an
alias, and invoke that function to perform the completion.  This has
no effect on git commands, because they can not be aliased anyway.  If
it is an alias and there is a completion function for that alias (e.g.
_git_foo() for the alias 'foo'), then it will be invoked to perform
completion, allowing users to provide custom completion functions for
aliases.  If such a completion function can not be found, only then
will the completion script check whether the command given on the
command line is an alias or not, and proceed as usual (i.e. find out
the aliased git command and provide completion for it).

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bash: support user-supplied completion scripts for user's git commands

The bash completion script already provides support to complete
aliases, options and refs for aliases (if the alias can be traced back
to a supported git command by __git_aliased_command()), and the user's
custom git commands, but it does not support the options of the user's
custom git commands (of course; how could it know about the options of
a custom git command?).  Users of such custom git commands could
extend git's bash completion script by writing functions to support
their commands, but they might have issues with it: they might not
have the rights to modify a system-wide git completion script, and
they will need to track and merge upstream changes in the future.

This patch addresses this by providing means for users to supply
custom completion scriplets for their custom git commands without
modifying the main git bash completion script.

Instead of having a huge hard-coded list of command-completion
function pairs (in _git()), the completion script will figure out
which completion function to call based on the command's name.  That
is, when completing the options of 'git foo', the main completion
script will check whether the function '_git_foo' is declared, and if
declared, it will invoke that function to perform the completion.  If
such a function is not declared, it will fall back to complete file
names.  So, users will only need to provide this '_git_foo' completion
function in a separate file, source that file, and it will be used the
next time they press TAB after 'git foo '.

There are two git commands (stage and whatchanged), for which the
completion functions of other commands were used, therefore they
got their own completion function.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bash: improve aliased command recognition

To support completion for aliases, the completion script tries to
figure out which git command is invoked by an alias.  Its
implementation in __git_aliased_command() is rather straightforward:
it returns the first word from the alias.  For simple aliases starting
with the git command (e.g. alias.last = cat-file commit HEAD) this
gives the right results.  Unfortunately, it does not work with shell
command aliases, which can get rather complex, as illustrated by one
of Junio's aliases:

[alias]
    lgm = "!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \"$@\" || :' -"

In this case the current implementation returns "!sh" as the aliased
git command, which is obviosly wrong.

The full parsing of a shell command alias like that in the completion
code is clearly unfeasible.  However, we can easily improve on aliased
command recognition by eleminating stuff that is definitely not a git
command: shell commands (anything starting with '!'), command line
options (anything starting with '-'), environment variables (anything
with a '=' in it), and git itself.  This way the above alias would be
handled correctly, and the completion script would correctly recognize
"log" as the aliased git command.

Of course, this solution is not perfect either, and could be fooled
easily.  It's not hard to construct an alias, in which a word does not
match any of these filter patterns, but is still not a git command
(e.g.  by setting an environment variable to a value which contains
spaces).  It may even return false positives, when the output of a git
command is piped into an other git command, and the second gets the
command line options via $@, but options for the first one are
offered.  However, the following patches will enable the user to
supply custom completion scripts for aliases, which can be used to
remedy these problematic cases.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  am: remove rebase-apply directory before gc
  rerere: fix memory leak if rerere images can't be read
  Documentation: mention conflict marker size argument (%L) for merge driver

am: remove rebase-apply directory before gc

When git am does an automatic gc it doesn't clean up the rebase-apply
directory until after this has finished.  This means that if the user
aborts the gc then future am or rebase operations will report that an
existing operation is in progress, which is undesirable and confusing.

Reported by Mark Brown <broonie@debian.org> through
http://bugs.debian.org/570966

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rerere: fix memory leak if rerere images can't be read

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Print RUNTIME_PREFIX warning only when GIT_TRACE is set

When RUNTIME_PREFIX is enabled, the installation prefix is derived by
trying a limited set of known locations where the git executable can
reside. If none of these is found, a warning is emitted.

When git is built in a directory that matches neither of these known names,
the warning would always be emitted when the uninstalled executable is run.
This is a problem on Windows, where gitk picks the uninstalled git when
invoked from the build directory and gets confused by the warning.

Print the warning only when GIT_TRACE is set.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Allow '+', '-' and '.' in remote helper names

According to relevant RFCs, in addition to alphanumerics, the following
characters are valid in URL scheme parts: '+', '-' and '.', but
currently only alphanumerics are allowed in remote helper names.

Allow those three characters in remote helper names (both 'foo://' and
'foo::' syntax).

Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: mention conflict marker size argument (%L) for merge driver

23a64c9e (conflict-marker-size: new attribute, 2010-01-16) introduced the
new attribute and also pass the conflict marker size as %L to merge driver
commands. This documents the substitution.

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

move encode_in_pack_object_header() to a better place

Commit 1b22b6c897 made duplicated versions of encode_header() into a
common version called encode_in_pack_object_header(). There is however
a better location that sha1_file.c for such a function though, as
sha1_file.c contains nothing related to the creation of packs, and
it is quite populated already.

Also the comment that was moved to the header file should really remain
near the function as it covers implementation details and provides no
information about the actual function interface.

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

Merge branch 'il/rev-glob'

add-interactive: fix bogus diff header line ordering

When we look at a patch for adding hunks interactively, we
first split it into a header and a list of hunks. Some of
the header lines, such as mode changes and deletion, however,
become their own selectable hunks. Later when we reassemble
the patch, we simply concatenate the header and the selected
hunks. This leads to patches like this:

  diff --git a/file b/file
  index d95f3ad..0000000
  --- a/file
  +++ /dev/null
  deleted file mode 100644
  @@ -1 +0,0 @@
  -content

Notice how the deletion comes _after_ the ---/+++ lines,
when it should come before.

In many cases, we can get away with this as git-apply
accepts the slightly bogus input. However, in the specific
case of a deletion line that is being applied via "apply
-R", this malformed patch triggers an assert in git-apply.
This comes up when discarding a deletion via "git checkout
-p".

Rather than try to make git-apply accept our odd input,
let's just reassemble the patch in the correct order.

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

Use git_mkstemp_mode instead of plain mkstemp to create object files

We used to unnecessarily give the read permission to group and others,
regardless of the umask, which isn't serious because the objects are
still protected by their containing directory, but isn't necessary
either.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git_mkstemps_mode: don't set errno to EINVAL on exit.

When reaching the end of git_mkstemps_mode, at least one call to open()
has been done, and errno has been set accordingly. Setting errno is
therefore not necessary, and actually harmfull since callers can't
distinguish e.g. permanent failure from ENOENT, which can just mean that
we need to create the containing directory.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Use git_mkstemp_mode and xmkstemp_mode in odb_mkstemp, not chmod later.

We used to create 0600 files, and then use chmod to set the group and
other permission bits to the umask. This usually has the same effect
as a normal file creation with a umask.

But in the presence of ACLs, the group permission plays the role of
the ACL mask: the "g" bits of newly created files are chosen according
to default ACL mask of the directory, not according to the umask, and
doing a chmod() on these "g" bits affect the ACL's mask instead of
actual group permission.

In other words, creating files with 0600 and then doing a chmod to the
umask creates files which are unreadable by users allowed in the
default ACL. To create the files without breaking ACLs, we let the
umask do it's job at the file's creation time, and get rid of the
later chmod.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git_mkstemp_mode, xmkstemp_mode: variants of gitmkstemps with mode argument.

gitmkstemps emulates the behavior of mkstemps, which is usually used
to create files in a shared directory like /tmp/, hence, it creates
files with permission 0600.

Add git_mkstemps_mode() that allows us to specify the desired mode, and
make git_mkstemps() a wrapper that always uses 0600 to call it. Later we
will use git_mkstemps_mode() when creating pack files.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Move gitmkstemps to path.c

This function used to be only a compatibility function, but we're
going to extend it and actually use it, so make it part of Git.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add a testcase for ACL with restrictive umask.

Right now, Git creates unreadable pack files on non-shared
repositories when the user has a umask of 077, even when the default
ACLs for the directory would give read/write access to a specific
user.

Loose object files are created world-readable, which doesn't break ACLs,
but isn't necessarily desirable.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Move 'builtin-*' into a 'builtin/' subdirectory

This shrinks the top-level directory a bit, and makes it much more
pleasant to use auto-completion on the thing. Instead of

[torvalds@nehalem git]$ em buil<tab>
Display all 180 possibilities? (y or n)
[torvalds@nehalem git]$ em builtin-sh
builtin-shortlog.c     builtin-show-branch.c  builtin-show-ref.c
builtin-shortlog.o     builtin-show-branch.o  builtin-show-ref.o
[torvalds@nehalem git]$ em builtin-shor<tab>
builtin-shortlog.c  builtin-shortlog.o
[torvalds@nehalem git]$ em builtin-shortlog.c

you get

[torvalds@nehalem git]$ em buil<tab> [type]
builtin/   builtin.h
[torvalds@nehalem git]$ em builtin [auto-completes to]
[torvalds@nehalem git]$ em builtin/sh<tab> [type]
shortlog.c     shortlog.o     show-branch.c  show-branch.o  show-ref.c     show-ref.o
[torvalds@nehalem git]$ em builtin/sho [auto-completes to]
[torvalds@nehalem git]$ em builtin/shor<tab> [type]
shortlog.c  shortlog.o
[torvalds@nehalem git]$ em builtin/shortlog.c

which doesn't seem all that different, but not having that annoying
break in "Display all 180 possibilities?" is quite a relief.

NOTE! If you do this in a clean tree (no object files etc), or using an
editor that has auto-completion rules that ignores '*.o' files, you
won't see that annoying 'Display all 180 possibilities?' message - it
will just show the choices instead.  I think bash has some cut-off
around 100 choices or something.

So the reason I see this is that I'm using an odd editory, and thus
don't have the rules to cut down on auto-completion.  But you can
simulate that by using 'ls' instead, or something similar.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: Fix race condition in t7006-pager

Pagers that do not consume their input are dangerous: for example,

 $ GIT_PAGER=: git log
 $ echo $?
 141
 $

The only reason these tests were able to work before was that
'git log' would write to the pipe (and not fill it) before the
pager had time to terminate and close the pipe.

Fix it by using a program that consumes its input, namely wc (as
suggested by Johannes).

Reported-by: Johannes Sixt <j.sixt@viscovery.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1_file: be paranoid when creating loose objects

We don't want the data being deflated and stored into loose objects
to be different from what we expect.  While the deflated data is
protected by a CRC which is good enough for safe data retrieval
operations, we still want to be doubly sure that the source data used
at object creation time is still what we expected once that data has
been deflated and its CRC32 computed.

The most plausible data corruption may occur if the source file is
modified while Git is deflating and writing it out in a loose object.
Or Git itself could have a bug causing memory corruption.  Or even bad
RAM could cause trouble.  So it is best to make sure everything is
coherent and checksum protected from beginning to end.

To do so we compute the SHA1 of the data being deflated _after_ the
deflate operation has consumed that data, and make sure it matches
with the expected SHA1.  This way we can rely on the CRC32 checked by
the inflate operation to provide a good indication that the data is still
coherent with its SHA1 hash.  One pathological case we ignore is when
the data is modified before (or during) deflate call, but changed back
before it is hashed.

There is some overhead of course. Using 'git add' on a set of large files:

Before:

real    0m25.210s
user    0m23.783s
sys     0m1.408s

After:

real    0m26.537s
user    0m25.175s
sys     0m1.358s

The overhead is around 5% for full data coherency guarantee.

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

git-diff: add a test for git diff --quiet -w

This patch adds two test cases for:

6977c25 git diff --quiet -w: check and report the status

Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ml/maint-grep-doc'

* ml/maint-grep-doc:
  grep documentation: clarify what files match

Merge branch 'tc/maint-transport-ls-remote-with-void'

* tc/maint-transport-ls-remote-with-void:
  transport: add got_remote_refs flag

Merge branch 'hm/maint-imap-send-crlf'

* hm/maint-imap-send-crlf:
  git-imap-send: Convert LF to CRLF before storing patch to draft box

Merge branch 'sp/push-sideband'

* sp/push-sideband:
  receive-pack: Send internal errors over side-band #2
  t5401: Use a bare repository for the remote peer
  receive-pack: Send hook output over side band #2
  receive-pack: Wrap status reports inside side-band-64k
  receive-pack: Refactor how capabilities are shown to the client
  send-pack: demultiplex a sideband stream with status data
  run-command: support custom fd-set in async
  run-command: Allow stderr to be a caller supplied pipe

Merge branch 'jc/checkout-detached'

* jc/checkout-detached:
  Reword "detached HEAD" notification

Merge branch 'jc/maint-fix-test-perm'

* jc/maint-fix-test-perm:
  lib-patch-mode.sh: Fix permission
  t6000lib: Fix permission

Merge branch 'jn/makefile-script-lib'

* jn/makefile-script-lib:
  Do not install shell libraries executable

Merge branch 'mv/request-pull-modernize'

* mv/request-pull-modernize:
  request-pull: avoid mentioning that the start point is a single commit

hash-object: don't use mmap() for small files

Using read() instead of mmap() can be 39% speed up for 1Kb files and is
1% speed up 1Mb files. For larger files, it is better to use mmap(),
because the difference between is not significant, and when there is not
enough memory, mmap() performs much better, because it avoids swapping.

Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1_file: don't malloc the whole compressed result when writing out objects

There is no real advantage to malloc the whole output buffer and
deflate the data in a single pass when writing loose objects. That is
like only 1% faster while using more memory, especially with large
files where memory usage is far more. It is best to deflate and write
the data out in small chunks reusing the same memory instead.

For example, using 'git add' on a few large files averaging 40 MB ...

Before:
21.45user 1.10system 0:22.57elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+828040outputs (0major+142640minor)pagefaults 0swaps

After:
21.50user 1.25system 0:22.76elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+828040outputs (0major+104408minor)pagefaults 0swaps

While the runtime stayed relatively the same, the number of minor page
faults went down significantly.

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

t7006-pager: if stdout is not a terminal, make a new one

Testing pagination requires (fake or real) access to a terminal so we
can see whether the pagination automatically kicks in, which makes it
hard to get good coverage when running tests without --verbose.  There
are a number of ways to work around that:

 - Replace all isatty calls with calls to a custom xisatty wrapper
   that usually checks for a terminal but can be overridden for tests.
   This would be workable, but it would require implementing xisatty
   separately in three languages (C, shell, and perl) and making sure
   that any code that is to be tested always uses the wrapper.

 - Redirect stdout to /dev/tty.  This would be problematic because
   there might be no terminal available, and even if a terminal is
   available, it might not be appropriate to spew output to it.

 - Create a new pseudo-terminal on the fly and capture its output.

This patch implements the third approach.

The new test-terminal.perl helper uses IO::Pty from Expect.pm to create
a terminal and executes the program specified by its arguments with
that terminal as stdout.  If the IO::Pty module is missing or not
working on a system, the test script will maintain its old behavior
(skipping most of its tests unless GIT_TEST_OPTS includes --verbose).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  git-p4: fix bug in symlink handling
  t1450: fix testcases that were wrongly expecting failure
  Documentation: Fix indentation problem in git-commit(1)

cherry_pick_list: quit early if one side is empty

The --cherry-pick logic starts by counting the commits on each side,
so that it can filter away commits on the bigger one.  However, so
far it missed an opportunity for optimization: it doesn't need to do
any work if either side is empty.

This in particular helps the common use-case 'git rebase -i HEAD~$n':
it internally uses --cherry-pick, but since HEAD~$n is a direct
ancestor the left side is always empty.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: Add tests for automatic use of pager

Git’s automatic pagination support has some subtleties.  Add some
tests to make sure we don’t break:

 - when git will use a pager by default;
 - the effect of the --paginate and --no-pager options;
 - the effect of pagination on use of color;
 - how the choice of pager is configured.

This does not yet test:

 - use of pager by scripted commands (git svn and git am);
 - effect of the pager.* configuration variables;
 - setting of the LESS variable.

Some features involve checking whether stdout is a terminal, so many
of these tests are skipped unless output is passed through to the
terminal (i.e., unless $GIT_TEST_OPTS includes --verbose).

The immediate purpose for these tests was to avoid making things worse
after the breakage from my jn/editor-pager series (see commit 376f39,
2009-11-20).  Thanks to Sebastian Celis <sebastian@sebastiancelis.com>
for the report.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: pack-objects: Clarify --local's semantics.

The current documentation suggests that --local also ignores any
objects in local packs, which is incorrect. Change the language to be
clearer and more parallel to the other options that ignore objects.

While we're at it, fix a trivial error in --incremental's
documentation.

Signed-off-by: Nelson Elhage <nelhage@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

utf8.c: speculatively assume utf-8 in strbuf_add_wrapped_text()

is_utf8() works by calling utf8_width() for each character at the
supplied location.  In strbuf_add_wrapped_text(), we do that anyway
while wrapping the lines.  So instead of checking the encoding
beforehand, optimistically assume that it's utf-8 and wrap along
until an invalid character is hit, and when that happens start over.

This pays off if the text consists only of valid utf-8 characters.
The following command was run against the Linux kernel repo with
git 1.7.0:

$ time git log --format='%b' v2.6.32 >/dev/null

real 0m2.679s
user 0m2.580s
sys 0m0.100s

$ time git log --format='%w(60,4,8)%b' >/dev/null

real 0m4.342s
user 0m4.230s
sys 0m0.110s

And with this patch series:

$ time git log --format='%w(60,4,8)%b' >/dev/null

real 0m3.741s
user 0m3.630s
sys 0m0.110s

So the cost of wrapping is reduced to 70% in this case.

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

utf8.c: remove strbuf_write()

The patch before the previous one made sure that all callers of
strbuf_add_wrapped_text() supply a strbuf.  Replace all calls of
strbuf_write() with regular strbuf functions and remove it.

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

utf8.c: remove print_spaces()

The previous patch made sure that strbuf_add_wrapped_text() (and thus
strbuf_add_indented_text(), too) always get a strbuf.  Make use of
this fact by adding strbuf_addchars(), a small helper that adds a
char the specified number of times to a strbuf, and use it to replace
print_spaces().

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