git-add--interactive: manual hunk editing mode

Adds a new option 'e' to the 'add -p' command loop that lets you edit
the current hunk in your favourite editor.

If the resulting patch applies cleanly, the edited hunk will
immediately be marked for staging. If it does not apply cleanly, you
will be given an opportunity to edit again. If all lines of the hunk
are removed, then the edit is aborted and the hunk is left unchanged.

Applying the changed hunk(s) relies on Johannes Schindelin's new
--recount option for git-apply.

Note that the "real patch" test intentionally uses
  (echo e; echo n; echo d) | git add -p
even though the 'n' and 'd' are superfluous at first sight.  They
serve to get out of the interaction loop if git add -p wrongly
concludes the patch does not apply.

Many thanks to Jeff King <peff@peff.net> for lots of help and
suggestions.

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

git-add--interactive: remove hunk coalescing

Current git-apply has no trouble at all applying chunks that have
overlapping context, as produced by the splitting feature. So we can
drop the manual coalescing.

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

git-add--interactive: replace hunk recounting with apply --recount

We recounted the postimage offsets to compensate for hunks that were
not selected.  Now apply --recount can do the job for us.

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

git fetch-pack: do not complain about "no common commits" in an empty repo

If the repo is empty, it is obvious that there are no common commits
when fetching from _anywhere_.

So there is no use in saying it in that case, and it can even be
annoying.  Therefore suppress the message unilaterally if the repository
is empty prior to the fetch.

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

Documentation: Point to gitcli(7) from git(1)

Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes for 1.6.0

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

gitcli: Document meaning of --cached and --index

We saw this explanation repeated on the mailing list a few times.  Even
though the description of individual options to particular commands are
explained in their manual pages, the reason behind choosing which is which
has not been clearly explained in any of the documentation.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation formatting and cleanup

Following what appears to be the predominant style, format
names of commands and commandlines both as `teletype text`.

While we're at it, add articles ("a" and "the") in some
places, italicize the name of the command in the manual page
synopsis line, and add a comma or two where it seems appropriate.

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

Documentation: be consistent about "git-" versus "git "

Since the git-* commands are not installed in $(bindir), using
"git-command <parameters>" in examples in the documentation is
not a good idea. On the other hand, it is nice to be able to
refer to each command using one hyphenated word. (There is no
escaping it, anyway: man page names cannot have spaces in them.)

This patch retains the dash in naming an operation, command,
program, process, or action. Complete command lines that can
be entered at a shell (i.e., without options omitted) are
made to use the dashless form.

The changes consist only of replacing some spaces with hyphens
and vice versa. After a "s/ /-/g", the unpatched and patched
versions are identical.

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

Documentation: prepare to be consistent about "git-" versus "git "

With the dashed forms of git commands not in $(bindir), we have
to change many instances of "git-command" to "git command". Also,
for consistency it is at times appropriate to make the opposite
change. In some cases, the change is not so simple as changing one
character.

This patch gets rid of some of those cases by rewrapping lines.

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

git-daemon(1): don't assume git-daemon is in /usr/bin

In the example inetd.conf lines in git-daemon(1), it was
assumed that `git-daemon` resides in the user's /usr/bin.
With this patch, we only assume `git` is in /usr/bin.

The stronger assumption fails in the default installation
nowadays.

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

Documentation: complicate example of "man git-command"

The manual page for the command invoked as "git clone" is named
git-clone(1), and similarly for the rest of the git commands.
Make sure our first example of this in tutorials makes it clear
that it is the first two words of a command line that make up the
command's name (that is: for example, the effect of "git svn
dcommit" is described in git-svn(1)).

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

whitespace fix in Documentation/git-repack.txt

Change leading spaces to tabs to match the rest of the file.

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

Documentation: fix links to tutorials and other new manual pages

With the conversion of HTML documentation to man pages

tutorial.html -> gittutorial (7)
tutorial-2.html -> gittutorial-2 (7)
cvs-migration.html -> gitcvs-migration (7)
diffcore.html -> gitdiffcore (7)
repository-layout.html -> gitrepository-layout (5)
hooks.html -> githooks (5)
glossary.html -> gitglossary (7)
core-tutorial.html -> gitcore-tutorial (7)

and the automatic update of references to these pages,
a little debris was left behind. We clear it away.

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

Merge maint in

Start draft release notes for 1.5.6.2

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

Fix 'git show' on signed tag of signed tag of commit

The cmd_show loop resolves tags by showing them, then pointing the
object to the 'tagged' member.  However, this object is not fully
initialized; it only contains the SHA1.  (This resulted in a segfault
if there were two levels of tags.)  We apply parse_object to get a
full object.

Noticed by Kalle Olavi Niemitalo on IRC.

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

Merge branch 'ph/mergetool'

* ph/mergetool:
  Remove the use of '--' in merge program invocation

Merge branch 'js/apply-recount'

* js/apply-recount:
  Allow git-apply to recount the lines in a hunk (AKA recountdiff)

Merge branch 'jc/checkdiff'

* jc/checkdiff:
  Fix t4017-diff-retval for white-space from wc
  Update sample pre-commit hook to use "diff --check"
  diff --check: detect leftover conflict markers
  Teach "diff --check" about new blank lines at end
  checkdiff: pass diff_options to the callback
  check_and_emit_line(): rename and refactor
  diff --check: explain why we do not care whether old side is binary

Merge branch 'kb/send-email-fifo'

* kb/send-email-fifo:
  git-send-email: Accept fifos as well as files

Merge branch 'tr/send-email-ssl'

* tr/send-email-ssl:
  git-send-email: prevent undefined variable warnings if no encryption is set
  git-send-email: add support for TLS via Net::SMTP::SSL

Merge branch 'js/maint-clone-insteadof'

* js/maint-clone-insteadof:
  clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
  clone: respect url.insteadOf setting in global configs

Merge branch 'jc/maint-reset'

* jc/maint-reset:
  Allow "git-reset path" when unambiguous

Merge branch 'jk/maint-fetch-ref-hier'

* jk/maint-fetch-ref-hier:
  fetch: give a hint to the user when local refs fail to update
  fetch: report local storage errors in status table

Merge branch 'dz/apply-again'

* dz/apply-again:
  git-apply: handle a patch that touches the same path more than once better

Merge branch 'np/pack-default'

* np/pack-default:
  pack.indexversion config option now defaults to 2
  repack.usedeltabaseoffset config option now defaults to "true"

Merge branch 'jc/dashless' (early part)

* 'jc/dashless' (early part):
  Prepare execv_git_cmd() for removal of builtins from the filesystem
  git-shell: accept "git foo" form

Merge branch 'nd/dashless'

* nd/dashless:
  Keep some git-* programs in $(bindir)
  Move all dashed-form commands to libexecdir

Merge branch 'maint'

* maint:
  doc/rev-parse: clarify reflog vs --until for specifying revisions

Add test results directory to t/.gitignore

We don't need test results to be committed if we're fixing a test.

Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: give a hint to the user when local refs fail to update

There are basically two categories of update failures for
local refs:

  1. problems outside of git, like disk full, bad
     permissions, etc.

  2. D/F conflicts on tracking branch ref names

In either case, there should already have been an error
message. In case '1', hopefully enough information has
already been given that the user can fix it. In the case of
'2', we can hint that the user can clean up their tracking
branch area by using 'git remote prune'.

Note that we don't actually know _which_ case we have, so
the user will receive the hint in case 1, as well. In this
case the suggestion won't do any good, but hopefully the
user is smart enough to figure out that it's just a hint.

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

doc/rev-parse: clarify reflog vs --until for specifying revisions

The rev-parse manpage introduces the branch@{date} syntax,
and mentions the reflog specifically. However, new users may
not be familiar with the distinction between the reflog and
the commit date, so let's help them out with a "you may be
interested in --until" pointer.

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

Update draft release notes for 1.6.0

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

Documentation: don't assume git-sh-setup and git-parse-remote are in PATH

When git-parse-remote and git-sh-setup are not installed in
$(bindir) anymore, the shell script library won't be found on
user's $PATH in general.

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

t9700: skip when Test::More is not available

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

clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig

After initializing the config in the newly-created repository, we
need to unset GIT_CONFIG so that the global configs are read again.

Noticed by Pieter de Bie.

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

Fix t4017-diff-retval for white-space from wc

Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  git-svn: don't sanitize remote names in config
  git-svn: avoid filling up the disk with temp files.
  git cat-file: Fix memory leak in batch mode
  fix git config example syntax
  avoid off-by-one error in run_upload_archive

git-svn: don't sanitize remote names in config

The original sanitization code was just taken from the
remotes2config.sh shell script in contrib.

Credit to Avery Pennarun for noticing this mistake, and Junio
for clarifying the rules for config section names:

Junio C Hamano wrote in <7vfxr23s6m.fsf@gitster.siamese.dyndns.org>:

> In
>
>  [foo "bar"] baz = value
>
> foo and baz must be config.c::iskeychar() (and baz must be isalpha()), but
> "bar" can be almost anything.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

show_stats(): fix stats width calculation

Before this patch, name_width becomes negative or null for width values
less than 15 and name_width values greater than 25 (default: 50). This
leads to output random data.

This patch checks for minimal width and name_width values.

Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: remove {show,whatchanged}.difftree config options

This removes, from the documentation and the bash completion script, the
two config options that were introduced by the git-whatchanged.sh script
and lost in the C rewrite. Today, we can use aliases as an alternative.

Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: avoid filling up the disk with temp files.

Commit ffe256f9bac8a40ff751a9341a5869d98f72c285 ("git-svn: Speed up fetch")
introduced changes that create a temporary file for each object fetched by
svn.  These files should be deleted automatically, but perl apparently
doesn't do this until the process exits (or perhaps when its garbage
collector runs).

This means that on a large fetch, especially with lots of branches, we
sometimes fill up /tmp completely, which prevents the next temp file from
being written completely.  This is aggravated by the fact that a new temp
file is created for each updated file, even if that update produces a file
identical to one already in git.  Thus, it can happen even if there's lots
of disk space to store the finished repository.

We weren't adequately checking for write errors, so this would result in an
invalid file getting committed, which caused git-svn to fail later with an
invalid checksum.

This patch adds a check to syswrite() so similar problems don't lead to
corruption in the future.  It also unlink()'s each temp file explicitly
when we're done with it, so the disk doesn't need to fill up.

Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Tested-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git cat-file: Fix memory leak in batch mode

When run in batch mode, git cat-file never frees the memory for the blob
contents it is printing. This quickly adds up and causes git-svn to be
hardly usable for imports of large svn repos, because it uses cat-file in
batch mode and cat-file's memory usage easily reaches several hundred MB
without any good reason.

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

git-send-email: prevent undefined variable warnings if no encryption is set

With the previous patch, not configuring any encryption (either on or
off) would leave $smtp_encryption undefined.  We simply set it to the
empty string in that case.

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

fix git config example syntax

git-config expects a space, not '=' between option and value.

Also, quote the value since it contains globs, which some shells will not
pass through unchanged, or will abort if the glob doesn't expand.

Signed-off-by: Joey Hess <joey@kitenet.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

avoid off-by-one error in run_upload_archive

Make sure that buf has enough space to store the trailing \0 of
the command line argument, too.

Signed-off-by: Jochen Voss <voss@seehuhn.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT-VERSION-GEN: do not fail if a 'HEAD' file exists in the working copy

Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Allow git-apply to recount the lines in a hunk (AKA recountdiff)

Sometimes, the easiest way to fix up a patch is to edit it directly, even
adding or deleting lines.  Now, many people are not as divine as certain
benevolent dictators as to update the hunk headers correctly at the first
try.

So teach the tool to do it for us.

[jc: with tests]

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

commit-tree: lift completely arbitrary limit of 16 parents

There is no really good reason to have a merge with more than 16
parents, but we have a history of giving our users rope.

Combined with the fact that there was no good reason for that
arbitrary limit in the first place, here is an all-too-easy to fix.

Kind of wished-for by Len Brown.

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

shrink git-shell by avoiding redundant dependencies

A lot of modules that have nothing to do with git-shell functionality
were linked in, bloating git-shell more than 8 times.

This patch cuts off redundant dependencies by:
1. providing stubs for three functions that make no sense for git-shell;
2. moving quote_path_fully from environment.c to quote.c to make the
   later self sufficient;
3. moving make_absolute_path into a new separate file.

The following numbers have been received with the default optimization
settings on master using GCC 4.1.2:

Before:
   text    data     bss     dec     hex filename
 143915    1348   93168  238431   3a35f git-shell

After:
   text    data     bss     dec     hex filename
  17670     788    8232   26690    6842 git-shell

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

help: check early if we have a command, if not try a documentation topic

Before this patch, something like "git help tutorial" did not work,
people had to use "git help gittutorial" which is not very intuitive.

This patch uses the "is_git_command" function to test early if the
argument passed to "git help" is a git command, and if this is not the
case then we prefix the argument with "git" instead of "git-".

This way, things like "git help tutorial" or "git help glossary" will
work fine.

The little downside of this patch is that the "is_git_command" is a
little bit slow.

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

git-apply: handle a patch that touches the same path more than once better

When working with a lot of people who backport patches all day long, every
once in a while I get a patch that modifies the same file more than once
inside the same patch.  git-apply either fails if the second change relies
on the first change or silently drops the first change if the second change
is independent.

The silent part is the scary scenario for us.  Also this behaviour is
different from the patch-utils.

I have modified git-apply to create a table of the filenames of files it
modifies such that if a later patch chunk modifies a file in the table it
will buffer the previously changed file instead of reading the original file
from disk.

Logic has been put in to handle creations/deletions/renames/copies.  All the
relevant tests of git-apply succeed.

A new test has been added to cover the cases I addressed.

The fix is relatively straight-forward.

Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: report local storage errors in status table

Previously, if there was an error while storing a local
tracking ref, the low-level functions would report an error,
but fetch's status output wouldn't indicate any problem.
E.g., imagine you have an old "refs/remotes/origin/foo/bar" but
upstream has deleted "foo/bar" in favor of a new branch
"foo". You would get output like this:

  error: there are still refs under 'refs/remotes/origin/foo'
  From $url_of_repo
   * [new branch]      foo        -> origin/foo

With this patch, the output takes into account the status of
updating the local ref:

  error: there are still refs under 'refs/remotes/origin/foo'
  From $url_of_repo
   ! [new branch]      foo        -> origin/foo  (unable to update local ref)

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

clone: respect url.insteadOf setting in global configs

When we call "git clone" with a url that has a rewrite rule in either
$HOME/.gitconfig or /etc/gitconfig, the URL can be different from
what the command line expects it to be.

So, let's use the URL as the remote structure has it, not the literal
string from the command line.

Noticed by Pieter de Bie.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Document the double-dash "rev -- path" disambiguator

This is a very well established command line convention that old residents
of the git mailing list knew by heart and nobody even thought about
documenting it explicitly, which was not very nice.

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

Update sample pre-commit hook to use "diff --check"

Now "diff --check" can detect not just whitespace errors but also notices
leftover conflict marker lines, we can use it in the sample pre-commit
hook script.

These days the object layer knows about the empty tree object without
actually having one in the repository, so we can run the test even for the
initial commit.

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

diff --check: detect leftover conflict markers

This teaches "diff --check" to detect and complain if the change
adds lines that look like leftover conflict markers.

We should be able to remove the old Perl script used in the sample
pre-commit hook and modernize the script with this facility.

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

Teach "diff --check" about new blank lines at end

When a patch adds new blank lines at the end, "git apply --whitespace"
warns.  This teaches "diff --check" to do the same.

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

checkdiff: pass diff_options to the callback

This way, we could later use more information from the diff_options.

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

Don't use dash commands (git-foo) in tutorial-2

Signed-off-by: Ted Percival <ted@midg3t.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-lib.sh: show git init output when in verbose mode

Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

check_and_emit_line(): rename and refactor

The function name was too bland and not explicit enough as to what it is
checking.  Split it into two, and call the one that checks if there is a
whitespace breakage "ws_check()", and call the other one that checks and
emits the line after color coding "ws_check_emit()".

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

diff --check: explain why we do not care whether old side is binary

All other codepaths refrain from running textual diff when either the old
or the new side is binary, but this function only checks the new side.  I
was almost going to change it to check both, but that would be a bad
change.  Explain why to prevent future mistakes.

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

Merge branch 'maint'

* maint:
  GIT 1.5.5.5
  GIT 1.5.4.6
  git-shell: accept "git foo" form
  diff --check: do not discard error status upon seeing a good line

Merge branch 'maint-1.5.5' into maint

* maint-1.5.5:
  GIT 1.5.5.5
  GIT 1.5.4.6
  git-shell: accept "git foo" form

Conflicts:

GIT-VERSION-GEN
RelNotes

GIT 1.5.5.5

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

Merge branch 'maint-1.5.4' into maint-1.5.5

* maint-1.5.4:
  GIT 1.5.4.6
  git-shell: accept "git foo" form

Conflicts:

GIT-VERSION-GEN
RelNotes

GIT 1.5.4.6

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

git-shell: accept "git foo" form

This is a backport of 0a47dc110e042b5bcc63dc94c8d517e67efe9306
to 'maint' to be included in 1.5.6.2 so that older server side
can accept dashless form of request when clients are updated.

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

diff --check: do not discard error status upon seeing a good line

"git diff --check" should return non-zero when there was any whitespace
error but the code only paid attention to the error status of the last
new line in the patch.

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

improve for-each-ref test script

Previously, we did a sanity check by doing for-each-ref
using each possible format atom. However, we never checked
the actual output produced by that atom, which recently let
an obvious bug go undetected for some time.

While we're at it, also clean up a few '!' into
test_must_fail.

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

Add 'git-p4.allowSubmit' to git-p4

I'm working with a perforce repo using git-p4. There are some config
files which I need to change locally according to my environment. I'm
using a 'local' git branch to park these changes. And I want to avoid
accidentally checking them into p4 just by doing "git p4 submit"
mindlessly without realizing which branch I'm actually on.

This patch adds a new git config, 'git-p4.allowSubmit', which is a
whitelist of branch names. "git p4 submit" will only allow submissions
from local branches on the list. Useful for preventing inadvertently
submitting from a strictly local branch.

For backward compatibility, if this config is not set at all,
submissions from all branches are allowed.

Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
Acked-By: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start draft release notes for 1.6.0

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

update-hook-example: optionally allow non-fast-forward

Sometimes it is desirable to have non-fast-forward branches in a
shared repository. A typical example of that is the 'pu' branch.
This patch extends the format of allowed-users and allow-groups
files by using the '+' sign at the beginning as the mark that
non-fast-forward pushes are permitted to the branch.

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

git-send-email: add support for TLS via Net::SMTP::SSL

We do this by handing over the Net::SMTP instance to Net::SMTP::SSL,
which avoids Net::SMTP::TLS and its weird error checking.  This trick
is due to Brian Evins.

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

git-send-email: Accept fifos as well as files

When a fifo is given, validation must be skipped because we can't
read the fifo twice. Ideally git-send-email would cache the read
data instead of attempting to read twice, but for now just skip
validation.

Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack.indexversion config option now defaults to 2

As announced for 1.6.0.

Git older than version 1.5.2 (or any other git version with this option
set to 1) may revert to version 1 of the pack index by manually deleting
all .idx files and recreating them using 'git index-pack'.  Communication
over the git native protocol is unaffected since the pack index is never
transferred.

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

Merge branch 'maint'

* maint:
  GIT 1.5.6.1
  fix update-hook-example to work with packed tag references
  clone: create intermediate directories of destination repo
  for-each-ref: implement missing tag values
  git-rebase.sh: Add check if rebase is in progress

Allow "git-reset path" when unambiguous

Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.

This updates the command to follow the general rule:

 * When -- appears, revs come before it, and paths come after it;

 * When there is no --, earlier ones are revs and the rest are paths, and
   we need to guess.  When lack of -- marker forces us to guess, we
   protect from user errors and typoes by making sure what we treat as
   revs do not appear as filenames in the work tree, and what we treat as
   paths do appear as filenames in the work tree, and by erroring out if
   that is not the case.  We tell the user to disambiguate by using -- in
   such a case.

which is employed elsewhere in the system.

When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:

    -- A:
     no explicit rev given; "A" and whatever follows it are paths.

    A --:
        explicit rev "A" given and whatever follows the "--" are paths.

    A B:
       "A" could be rev or path and we need to guess.  "B" could
       be missing but if exists that (and everything that follows) would
       be paths.

So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).

 * As long as "A" is unambiguously a path, index entries for "A", "B" (and
   everything that follows) are reset to the HEAD revision.

 * If "A" is unambiguously a rev, on the other hand, the index entries for
   "B" (and everything that follows) are reset to the "A" revision.

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

Fix use of "perl -i" on Windows

The perldiag(1) has following to say about this:

    "Can't do inplace edit without backup"

(F) You're on a system such as MS-DOS that gets confused if
you try reading from a deleted (but still opened) file. You
have to say -i.bak, or some such.

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

GIT 1.5.6.1

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

Merge branch 'sb/rebase'

* sb/rebase:
  t3404: stricter tests for git-rebase--interactive
  api-builtin.txt: update and fix typo

Merge branch 'lw/gitweb'

* lw/gitweb:
  gitweb: standarize HTTP status codes

Merge branch 'lt/config-fsync'

* lt/config-fsync:
  Add config option to enable 'fsync()' of object files
  Split up default "i18n" and "branch" config parsing into helper routines
  Split up default "user" config parsing into helper routine
  Split up default "core" config parsing into helper routine

Merge branch 'sr/tests'

* sr/tests:
  Hook up the result aggregation in the test makefile.
  A simple script to parse the results from the testcases
  Modify test-lib.sh to output stats to t/test-results/*

Conflicts:

t/test-lib.sh

Merge branch 'jh/clone-packed-refs'

* jh/clone-packed-refs:
  Teach "git clone" to pack refs
  Prepare testsuite for a "git clone" that packs refs
  Move pack_refs() and friends into libgit
  Incorporate fetched packs in future object traversal

Merge branch 'lw/perlish'

* lw/perlish:
  Git.pm: add test suite
  t/test-lib.sh: add test_external and test_external_without_stderr

fix update-hook-example to work with packed tag references

The update-hook-example used 'test -f' to check the tag present, which
does not work if the checked reference is packed. This check has been
changed to use 'git rev-parse $tag' instead.

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

clone: create intermediate directories of destination repo

The shell version used to use "mkdir -p" to create the repo
path, but the C version just calls "mkdir". Let's replicate
the old behavior. We have to create the git and worktree
leading dirs separately; while most of the time, the
worktree dir contains the git dir (as .git), the user can
override this using GIT_WORK_TREE.

We can reuse safe_create_leading_directories, but we need to
make a copy of our const buffer to do so. Since
merge-recursive uses the same pattern, we can factor this
out into a global function. This has two other cleanup
advantages for merge-recursive:

  1. mkdir_p wasn't a very good name. "mkdir -p foo/bar" actually
     creates bar, but this function just creates the leading
     directories.

  2. mkdir_p took a mode argument, but it was completely
     ignored.

Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/maint-combine-diff-pre-context' into maint

* jc/maint-combine-diff-pre-context:
  diff -c/--cc: do not include uninteresting deletion before leading context

Merge branch 'lt/maint-gitdir-relative' into maint

* lt/maint-gitdir-relative:
  Make git_dir a path relative to work_tree in setup_work_tree()

Merge branch 'sb/maint-rebase' into maint

* sb/maint-rebase:
  git-rebase.sh: Add check if rebase is in progress

for-each-ref: implement missing tag values

The "type" and "object" fields for tags were accepted as
valid atoms, but never implemented. Consequently, they
simply returned the empty string, even for valid tags.

Noticed by Lea Wiemann.

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

repack.usedeltabaseoffset config option now defaults to "true"

As announced for 1.6.0.

Access over the native protocol by old git versions is unaffected as
this capability is negociated by the protocol.  Otherwise setting this
config option to "false" and doing a 'git repack -a -d' is enough to
remain compatible with ancient git versions (older than 1.4.4).

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

verify-pack: test for detection of index v2 object CRC mismatch

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

verify-pack: check packed object CRC when using index version 2

To do so, check_pack_crc() moved from builtin-pack-objects.c to
pack-check.c where it is more logical to share.

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

move show_pack_info() where it belongs

This is called when verify_pack() has its verbose argument set, and
verbose in this context makes sense only for the actual 'git verify-pack'
command.  Therefore let's move show_pack_info() to builtin-verify-pack.c
instead and remove useless verbose argument from verify_pack().

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

optimize verify-pack a bit

Using find_pack_entry_one() to get object offsets is rather suboptimal
when nth_packed_object_offset() can be used directly.

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

clone: create intermediate directories of destination repo

The shell version used to use "mkdir -p" to create the repo
path, but the C version just calls "mkdir". Let's replicate
the old behavior. We have to create the git and worktree
leading dirs separately; while most of the time, the
worktree dir contains the git dir (as .git), the user can
override this using GIT_WORK_TREE.

We can reuse safe_create_leading_directories, but we need to
make a copy of our const buffer to do so. Since
merge-recursive uses the same pattern, we can factor this
out into a global function. This has two other cleanup
advantages for merge-recursive:

  1. mkdir_p wasn't a very good name. "mkdir -p foo/bar" actually
     creates bar, but this function just creates the leading
     directories.

  2. mkdir_p took a mode argument, but it was completely
     ignored.

Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>