Merge branch 'jc/maint-apply-fix' into maint

* jc/maint-apply-fix:
  builtin-apply.c: do not set bogus mode in check_preimage() for deleted path

Merge branch 'am/maint-push-doc' into maint

* am/maint-push-doc:
  Documentation: rework src/dst description in git push
  Documentation: more git push examples
  Documentation: simplify refspec format description

Merge branch 'sg/maint-gitdir-in-subdir' into maint

* sg/maint-gitdir-in-subdir:
  Fix gitdir detection when in subdir of gitdir

Merge branch 'lt/maint-wrap-zlib' into maint

* lt/maint-wrap-zlib:
  Wrap inflate and other zlib routines for better error reporting

Conflicts:
http-push.c
http-walker.c
sha1_file.c

Merge branch 'jc/maint-split-diff-metainfo' into maint

* jc/maint-split-diff-metainfo:
  diff.c: output correct index lines for a split diff

Merge branch 'js/maint-all-implies-HEAD' into maint

* js/maint-all-implies-HEAD:
  bundle: allow the same ref to be given more than once
  revision walker: include a detached HEAD in --all

Merge branch 'kc/maint-diff-bwi-fix' into maint

* kc/maint-diff-bwi-fix:
  Fix combined use of whitespace ignore options to diff
  test more combinations of ignore-whitespace options to diff

filter-branch: do not consider diverging submodules a 'dirty worktree'

At the end of filter-branch in a non-bare repository, the work tree is
updated with "read-tree -m -u HEAD", to carry the change forward in case
the current branch was rewritten.  In order to avoid losing any local
change during this step, filter-branch refuses to work when there are
local changes in the work tree.

This "read-tree -m -u HEAD" operation does not affect what commit is
checked out in a submodule (iow, it does not touch .git/HEAD in a
submodule checkout), and checking if there is any local change to the
submodule is not useful.

Staged submodules _are_ considered to be 'dirty', however,  as the
"read-tree -m -u HEAD" could result in loss of staged information
otherwise.

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

Fixed broken git help -w when installing from RPM

After the git-core package was renamed to git, git help -w was still looking
for files in /usr/share/doc/git-core-$VERSION instead of
/usr/share/doc/git-$VERSION.

Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin-blame.c: Use utf8_strwidth for author's names

git blame misaligns output if a author's name has a differing display width and
strlen; for instance, an accented Latin letter that takes two bytes to encode
will cause the rest of the line to be shifted to the left by one. To fix this,
use utf8_strwidth instead of strlen (and compute the padding ourselves, since
printf doesn't know about UTF-8).

Signed-off-by: Geoffrey Thomas <geofft@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

utf8: add utf8_strwidth()

I'm about to use this pattern more than once, so make it a common function.

Signed-off-by: Geoffrey Thomas <geofft@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

urls.txt: document optional port specification in git URLS

Signed-off-by: Stefan Naewe <stefan.naewe+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  builtin-mv.c: check for unversionned files before looking at the destination.
  Add a testcase for "git mv -f" on untracked files.
  Missing && in t/t7001.sh.

builtin-mv.c: check for unversionned files before looking at the destination.

The previous code was failing in the case where one moves an
unversionned file to an existing destination, with mv -f: the
"existing destination" was checked first, and the error was cancelled
by the force flag.

We now check the unrecoverable error first, which fixes the bug.

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

Add a testcase for "git mv -f" on untracked files.

This currently fails with:
git: builtin-mv.c:217: cmd_mv: Assertion `pos >= 0' failed.

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

Missing && in t/t7001.sh.

Without this, the exit status is only the one of the last line.

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

builtin-remote: make rm operation safer in mirrored repository

"git remote rm <repo>" happily removes non-remote refs and their reflogs.
This may be okay if the repository truely is a mirror, but if the user
had done "git remote add --mirror <repo>" by accident and was just
undoing their mistake, then they are left in a situation that is
difficult to recover from.

After this commit, "git remote rm" skips over non-remote refs. The user
is advised on how remove branches using "git branch -d", which itself
has nice safety checks wrt to branch removal lacking from "git remote rm".
Non-remote non-branch refs are skipped silently.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  User-manual: "git stash <comment>" form is long gone
  add test-dump-cache-tree in Makefile
  fix typo in Documentation
  apply: fix access to an uninitialized mode variable, found by valgrind

User-manual: "git stash <comment>" form is long gone

These days you must explicitly say "git stash save <comment>".

Signed-off-by: William Pursell <bill.pursell@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add test-dump-cache-tree in Makefile

5c5ba73 (Makefile: Use generic rule to build test programs,
2007-05-31) tried to use generic rule to build test programs, but it
misses the file 'dump-cache-tree.c', since its name is not prefixed by
'test-'.  This commit solves this little problem by renaming this file
instead of carrying out an explicit rule in Makefile.

Signed-off-by: Guanqun Lu <guanqun.lu@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fix typo in Documentation

Signed-off-by: Guanqun Lu <guanqun.lu@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

apply: fix access to an uninitialized mode variable, found by valgrind

When 'tpatch' was initialized successfully, st_mode was already taken
from the previous diff.  We should not try to override it with data
from an lstat() that was never called.

This is a companion patch to 7a07841(git-apply: handle a patch that
touches the same path more than once better).

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

filter-branch: Fix fatal error on bare repositories

When git filter-branch is run on a bare repository, it prints out a fatal
error message:

  $ git filter-branch branch
  Rewrite 476c4839280c219c2317376b661d9d95c1727fc3 (9/9)
  WARNING: Ref 'refs/heads/branch' is unchanged
  fatal: This operation must be run in a work tree

Note that this fatal error message doesn't prevent git filter-branch from
exiting successfully. (Why doesn't git filter-branch actually exit with an
error when a shell command fails? I'm not sure why it was designed this
way.)

This error message is caused by the following section of code at the end of
git-filter-branch.sh:

  if [ "$(is_bare_repository)" = false ]; then
          unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
          test -z "$ORIG_GIT_DIR" || {
                  GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
          }
          ... elided ...
          git read-tree -u -m HEAD
  fi

The problem is the call to $(is_bare_repository), which is made before
GIT_DIR and GIT_WORK_TREE are restored.  This call always returns "false",
even when we're running in a bare repository.  But this means that we will
attempt to call 'git read-tree' even in a bare repository, which will fail
and print an error.

This patch modifies git-filter-branch.sh to restore the original
environment variables before trying to call is_bare_repository.

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

builtin-remote: make rm() use properly named variable to hold return value

"i" is a loop counter and should not be used to hold a return value; use
"result" instead which is consistent with the rest of builtin-remote.c.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  grep: pass -I (ignore binary) down to external grep

grep: pass -I (ignore binary) down to external grep

We forgot to pass this option to the external grep process.

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

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  merge: fix out-of-bounds memory access

merge: fix out-of-bounds memory access

The parameter n of unpack_callback() can have a value of up to
MAX_UNPACK_TREES.  The check at the top of unpack_trees() (its only
(indirect) caller) makes sure it cannot exceed this limit.

unpack_callback() passes it and the array src to unpack_nondirectories(),
which has this loop:

for (i = 0; i < n; i++) {
/* ... */
src[i + o->merge] = o->df_conflict_entry;

o->merge can be 0 or 1, so unpack_nondirectories() potentially accesses
the array src at index MAX_UNPACK_TREES.  This patch makes it big enough.

Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT 1.6.1.2

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

Merge branch 'jc/maint-format-patch-o-relative' into maint

* jc/maint-format-patch-o-relative:
  Teach format-patch to handle output directory relative to cwd

Conflicts:
t/t4014-format-patch.sh

Merge branch 'bs/maint-rename-populate-filespec' into maint

* bs/maint-rename-populate-filespec:
  Rename detection: Avoid repeated filespec population

Merge branch 'mh/maint-commit-color-status' into maint

* mh/maint-commit-color-status:
  git-status -v: color diff output when color.ui is set
  git-commit: color status output when color.ui is set

Merge branch 'nd/grep-assume-unchanged' into maint

* nd/grep-assume-unchanged:
  grep: grep cache entries if they are "assume unchanged"
  grep: support --no-ext-grep to test builtin grep

Merge branch 'jc/maint-ls-tree' into maint

* jc/maint-ls-tree:
  Document git-ls-tree --full-tree
  ls-tree: add --full-tree option

Merge branch 'np/no-loosen-prune-expire-now' into maint

* np/no-loosen-prune-expire-now:
  objects to be pruned immediately don't have to be loosened

Merge branch 'mc/cd-p-pwd' into maint

* mc/cd-p-pwd:
  git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  avoid 31-bit truncation in write_loose_object

avoid 31-bit truncation in write_loose_object

The size of the content we are adding may be larger than
2.1G (i.e., "git add gigantic-file"). Most of the code-path
to do so uses size_t or unsigned long to record the size,
but write_loose_object uses a signed int.

On platforms where "int" is 32-bits (which includes x86_64
Linux platforms), we end up passing malloc a negative size.

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

add -u: do not fail to resolve a path as deleted

After you resolve a conflicted merge to remove the path, "git add -u"
failed to record the removal.  Instead it errored out by saying that the
removed path is not found in the work tree, but that is what the user
already knows, and the wanted to record the removal as the resolution,
so the error does not make sense.

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

builtin-apply.c: do not set bogus mode in check_preimage() for deleted path

If it is deleted, it is deleted.  Do not set the current mode to it.

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

mailinfo: tests for RFC2047 examples

Also as suggested by Junio, in order to try to catch other MIME
problems, test cases from the "8. Examples" section of RFC2047 are added
to t5100 testsuite as well.

Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>

mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'

Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>

Fix submodule squashing into unrelated commit

Actually, I think the issue is pretty independent of submodules; when
"git commit" gets an empty parameter, it misinterprets it as a file.

So avoid passing an empty parameter to "git commit".

Actually, this is a nice cleanup, as MSG_FILE and EDIT_COMMIT were mutually
exclusive; use one variable instead

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

rebase -i squashes submodule changes into unrelated commit

Attempting to rebase three-commit series (two regular changes, followed by
one commit that changes what commit is bound for a submodule path) to
squash the first two results in a failure; not just the first two commits
squashed, but the change to the submodule is also included in the result.

This failure causes the subsequent step to "pick" the change that actually
changes the submodule to be applied, because there is no change left to be
applied.

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

git: use run_command() to execute dashed externals

We used to simply try calling execvp(); if it succeeded, then we were done
and the new program was running. If it didn't, then we knew that it wasn't
a valid command.

Unfortunately, this interacted badly with the new pager handling. Now that
git remains the parent process and the pager is spawned, git has to hang
around until the pager is finished. We install an atexit handler to do
this, but that handler never gets called if we successfully run execvp.

You could see this behavior by running any dashed external using a pager
(e.g., "git -p stash list"). The command finishes running, but the pager
is still going. In the case of less, it then gets an error reading from
the terminal and exits, potentially leaving the terminal in a broken state
(and not showing the output).

This patch just uses run_command() to try running the dashed external. The
parent git process then waits for the external process to complete and
then handles the pager cleanup as it would for an internal command.

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

run_command(): help callers distinguish errors

run_command() returns a single integer specifying either an
error code or the exit status of the spawned program. The
only way to tell the difference is that the error codes are
outside of the allowed range of exit status values.

Rather than make each caller implement the test against a
magic limit, let's provide a macro.

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

run_command(): handle missing command errors more gracefully

When run_command() was asked to run a non-existant command, its behavior
varied depending on the platform:

  - on POSIX systems, we would fork, and then after the execvp call
    failed, we could call die(), which prints a message to stderr and
    exits with code 128.

  - on Windows, we do a PATH lookup, realize the program isn't there, and
    then return ERR_RUN_COMMAND_FORK

The goal of this patch is to make it clear to callers that the specific
error was a missing command. To do this, we will return the error code
ERR_RUN_COMMAND_EXEC, which is already defined in run-command.h, checked
for in several places, but never actually gets set.

The new behavior is:

  - on POSIX systems, we exit the forked process with code 127 (the same
    as the shell uses to report missing commands). The parent process
    recognizes this code and returns an EXEC error. The stderr message is
    silenced, since the caller may be speculatively trying to run a
    command. Instead, we use trace_printf so that somebody interested in
    debugging can see the error that occured.

  - on Windows, we check errno, which is already set correctly by
    mingw_spawnvpe, and report an EXEC error instead of a FORK error

Thus it is safe to speculatively run a command:

  int r = run_command_v_opt(argv, 0);
  if (r == -ERR_RUN_COMMAND_EXEC)
  /* oops, it wasn't found; try something else */
  else
  /* we failed for some other reason, error is in r */

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

git: s/run_command/run_builtin/

There is a static function called run_command which
conflicts with the library function in run-command.c; this
isn't a problem currently, but prevents including
run-command.h in git.c.

This patch just renames the static function to something
more specific and non-conflicting.

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

revision traversal: allow UNINTERESTING objects to be missing

Most of the existing codepaths were meant to treat missing uninteresting
objects to be a silently ignored non-error, but there were a few places
in handle_commit() and add_parents_to_list(), which are two key functions
in the revision traversal machinery, that cared:

 - When a tag refers to an object that we do not have, we barfed.  We
   ignore such a tag if it is painted as UNINTERESTING with this change.

 - When digging deeper into the ancestry chain of a commit that is already
   painted as UNINTERESTING, in order to paint its parents UNINTERESTING,
   we barfed if parse_parent() for a parent commit object failed.  We can
   ignore such a parent commit object.

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

send-pack: do not send unknown object name from ".have" to pack-objects

v1.6.1 introduced ".have" extension to the protocol to allow the receiving
side to advertise objects that are reachable from refs in the repositories
it borrows from.  This was meant to be used by the sending side to avoid
sending such objects; they are already available through the alternates
mechanism.

The client side implementation in v1.6.1, which was introduced with
40c155f (push: prepare sender to receive extended ref information from the
receiver, 2008-09-09) aka v1.6.1-rc1~203^2~1, were faulty in that it did
not consider the possiblity that the repository receiver borrows from
might have objects it does not know about.

This fixes it by refraining from passing missing commits to underlying
pack-objects.  Revision machinery may need to be tightened further to
treat missing uninteresting objects as non-error events, but this is an
obvious and safe fix for a maintenance release that is almost good enough.

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

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  test-path-utils: Fix off by one, found by valgrind
  get_sha1_basic(): fix invalid memory access, found by valgrind

test-path-utils: Fix off by one, found by valgrind

When normalizing an absolute path, we might have to add a slash _and_ a
NUL to the buffer, so the buffer was one too small.

Let's just future proof the code and alloc PATH_MAX + 1 bytes.

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

get_sha1_basic(): fix invalid memory access, found by valgrind

When get_sha1_basic() is passed a buffer of len 0, it should not
check if buf[len-1] is a curly bracket.

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

Merge branch 'jc/maint-1.6.0-split-diff-metainfo' into jc/maint-split-diff-metainfo

This is an evil merge, as a test added since 1.6.0 expects an incorrect
behaviour the merged commit fixes.

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

diff.c: output correct index lines for a split diff

A patch that changes the filetype (e.g. regular file to symlink) of a path
must be split into a deletion event followed by a creation event, which
means that we need to have two independent metainfo lines for each.
However, the code reused the single set of metainfo lines.

As the blob object names recorded on the index lines are usually not used
nor validated on the receiving end, this is not an issue with normal use
of the resulting patch.  However, when accepting a binary patch to delete
a blob, git-apply verified that the postimage blob object name on the
index line is 0{40}, hence a patch that deletes a regular file blob that
records binary contents to create a blob with different filetype (e.g. a
symbolic link) failed to apply.  "git am -3" also uses the blob object
names recorded on the index line, so it would also misbehave when
synthesizing a preimage tree.

This moves the code to generate metainfo lines around, so that two
independent sets of metainfo lines are used for the split halves.

Additional tests by Jeff King.

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

Documentation: rework src/dst description in git push

This tries to make the description of ref matching in git push easier
to read. Beauty is in the eye of the beholder, though.

Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: more git push examples

Include examples of using HEAD. The order of examples
introduces new concepts one by one. This pushes the
example of deleting a ref to the end of the list.

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

Documentation: simplify refspec format description

The refspec format description was a mix of regexp and BNF, making it
very difficult to read. The format was also wrong: it did not show
that each part of a refspec is optional in different situations.

Rather than having a confusing grammar, just present the format in
informal prose.

Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT 1.6.1.1

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

Merge branch 'cb/maint-unpack-trees-absense' into maint

* cb/maint-unpack-trees-absense:
  unpack-trees: remove redundant path search in verify_absent
  unpack-trees: fix path search bug in verify_absent
  unpack-trees: handle failure in verify_absent

Merge branch 'tr/maint-no-index-fixes' into maint

* tr/maint-no-index-fixes:
  diff --no-index -q: fix endless loop
  diff --no-index: test for pager after option parsing
  diff: accept -- when using --no-index

Merge branch 'rs/maint-shortlog-foldline' into maint

* rs/maint-shortlog-foldline:
  shortlog: handle multi-line subjects like log --pretty=oneline et. al. do

Merge branch 'pj/maint-ldflags' into maint

* pj/maint-ldflags:
  configure clobbers LDFLAGS

Merge branch 'pb/maint-git-pm-false-dir' into maint

* pb/maint-git-pm-false-dir:
  Git.pm: correctly handle directory name that evaluates to "false"

Merge branch 'js/maint-bisect-gitk' into maint

* js/maint-bisect-gitk:
  bisect view: call gitk if Cygwin's SESSIONNAME variable is set

Merge branch 'js/add-not-submodule' into maint

* js/add-not-submodule:
  git add: do not add files from a submodule

Merge branch 'jc/maint-format-patch' into maint

* jc/maint-format-patch:
  format-patch: show patch text for the root commit

Merge branch 'am/maint-push-doc' into maint

* am/maint-push-doc:
  Documentation: avoid using undefined parameters
  Documentation: mention branches rather than heads
  Documentation: remove a redundant elaboration
  Documentation: git push repository can also be a remote

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  Fix Documentation for git-describe

Fix Documentation for git-describe

The documentation for git-describe says the default abbreviation is 8
hexadecimal digits while cache.c clearly shows DEFAULT_ABBREV set to 7.
This patch corrects the documentation.

Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Rename diff.suppress-blank-empty to diff.suppressBlankEmpty

All the other config variables use CamelCase.  This config variable should
not be an exception.

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

Rename detection: Avoid repeated filespec population

In diffcore_rename, we assume that the blob contents in the filespec
aren't required anymore after estimate_similarity has been called and thus
we free it. But estimate_similarity might return early when the file sizes
differ too much. In that case, cnt_data is never set and the next call to
estimate_similarity will populate the filespec again, eventually rereading
the same blob over and over again.

To fix that, we first get the blob sizes and only when the blob contents
are actually required, and when cnt_data will be set, the full filespec is
populated, once.

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

Fix combined use of whitespace ignore options to diff

The code used to misbehave when options to ignore certain whitespaces
(-w -b and --ignore-at-eol) were combined.

Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test more combinations of ignore-whitespace options to diff

There are three flags involved (-w -b and --ignore-space-at-eol) which
makes 8 combinations possible in total, but only 3 cases are tested (none,
-w alone and -b alone).

This adds the other 5 cases.

Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

shell: Document that 'cvs server' is a valid command

git-shell's man page explicitly lists all allowed commands, but 'cvs
server' was missing. Add it.

Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: avoid using undefined parameters

The <ref> parameter has not been introduced, so rewrite to
avoid it.

Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: mention branches rather than heads

The "matching refs" semantics works only on matching branches these days.
Instead of using "heads" which traditionally has been used more or less
interchangeably with "refs", say "branch" explicitly here.

Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: remove a redundant elaboration

The comment in parentheses is wrong, as one has to leave out both the
colon and <dst>. This situation is covered by the section a few lines
down:

  A parameter <ref> without a colon pushes the <ref> from the source
  repository to the destination repository under the same name.

So, just remove the parentheses.

Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: git push repository can also be a remote

This is copied from pull-fetch-param.txt and helps the reader
to not get stuck in the URL section.

Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes for 1.6.1.1

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

bundle: allow the same ref to be given more than once

"git bundle create x master master" used to create a bundle that lists
the same branch (master) twice.  Cloning from such a bundle resulted in
a needless warning "warning: Duplicated ref: refs/remotes/origin/master".

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

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  builtin-fsck: fix off by one head count
  Documentation: let asciidoc align related options
  githooks.txt: add missing word
  builtin-commit.c: do not remove COMMIT_EDITMSG

builtin-fsck: fix off by one head count

According to the man page, if "git fsck" is passed one or more heads, it
should verify connectivity and validity of only objects reachable from the
heads it is passed.

However, since 5ac0a20 (Make builtin-fsck.c use parse_options.,
2007-10-15) the command behaved as if no heads were passed, when given
only one argument.

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

revision walker: include a detached HEAD in --all

When HEAD is detached, --all should list it, too, logically, as a
detached HEAD is by definition a temporary, unnamed branch.

It is especially necessary to list it when garbage collecting, as
the detached HEAD would be trashed.

Noticed by Thomas Rast.

Note that this affects creating bundles with --all; I contend that it
is a good change to add the HEAD, so that cloning from such a bundle
will give you a current branch.  However, I had to fix t5701 as it
assumed that --all does not imply HEAD.

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

Fix gitdir detection when in subdir of gitdir

If the current working directory is a subdirectory of the gitdir (e.g.
<repo>/.git/refs/), then setup_git_directory_gently() will climb its
parent directories until it finds itself in a gitdir.  However, no
matter how many parent directories it climbs, it sets
'GIT_DIR_ENVIRONMENT' to ".", which is obviously wrong.

This behaviour affected at least 'git rev-parse --git-dir' and hence
caused some errors in bash completion (e.g. customized command prompt
when on a detached head and completion of refs).

To fix this, we set the absolute path of the found gitdir instead.

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

t5540: clarify that http-push does not handle packed-refs on the remote

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

http-push: when making directories, have a trailing slash in the path name

The function lock_remote() sends MKCOL requests to make leading
directories; However, if it does not put a forward slash '/' at the end of
the path, the server sends a 301 redirect.

By leaving the '/' in place, we can avoid this additional step.

Incidentally, at least one version of Curl (7.16.3) does not resend
credentials when it follows a 301 redirect, so this commit also fixes
a bug.

Original patch by Tay Ray Chuan <rctay89@gmail.com>.

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

http-push: fix off-by-path_len

When getting the result of remote_ls(), we were advancing the variable
"path" to the relative path inside the repository.

However, then we went on to malloc a bogus amount of memory: we were
subtracting the prefix length _again_, quite possibly getting something
negative, which xmalloc() interprets as really, really much.

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

Documentation: let asciidoc align related options

Command line options can share the same paragraph of description, if
they are related or synonymous. In these cases they should be written
among each other, so that asciidoc can format them itself.

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

githooks.txt: add missing word

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin-commit.c: do not remove COMMIT_EDITMSG

git-commit tries to remove the file ./COMMIT_EDITMSG instead of
$GIT_DIR/COMMIT_EDITMSG after commit preparation (e.g. running
hooks, launching editor).
This behavior exists since f5bbc3225c4b07 "Port git commit to C".

Some test cases (e.g. t/t7502-commit.sh) rely on the existence of
$GIT_DIR/COMMIT_EDITMSG after committing and, I guess, many people
are used to it.  So it is best not to remove it.

This patch just removes the removal of COMMIT_EDITMSG.

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  t3404: Add test case for auto-amending only edited commits after "edit"
  t3404: Add test case for aborted --continue after "edit"
  t3501: check that commits are actually done

t3404: Add test case for auto-amending only edited commits after "edit"

Add a test case for the bugfix introduced by commit c14c3c82d
"git-rebase--interactive: auto amend only edited commit".

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3404: Add test case for aborted --continue after "edit"

Add a test case for the bugfix introduced by commit 8beb1f33d
"git-rebase-interactive: do not squash commits on abort".

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3501: check that commits are actually done

The basic idea of t3501 is to check whether revert
and cherry-pick works on renamed files.
But as there is no pure cherry-pick/revert test, it is
good to also check if commits are actually done in that
scenario.

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes to 1.6.1.1

Merge branch 'maint-1.6.0' into maint

* maint-1.6.0:
  fix handling of multiple untracked files for git mv -k
  add test cases for "git mv -k"

Make t3411 executable

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fix handling of multiple untracked files for git mv -k

The "-k" option to "git mv" should allow specifying multiple untracked
files. Currently, multiple untracked files raise an assertion if they
appear consecutively as arguments. Fix this by decrementing the loop
index after removing one entry from the array of arguments.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add test cases for "git mv -k"

Add test cases for ignoring nonexisting and untracked files using the -k
option to "git mv". There is one known breakage related to multiple
untracked files specfied as consecutive arguments.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>