Update draft release notes to 1.8.2

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

Merge branch 'maint'

* maint:
  Start preparing for 1.8.1.3

Merge branch 'jk/remote-helpers-in-python-3'

Prepare remote-helper test written in Python to be run with Python3.

* jk/remote-helpers-in-python-3:
  git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"
  git-remote-testpy: fix path hashing on Python 3
  git-remote-testpy: call print as a function
  git-remote-testpy: don't do unbuffered text I/O
  git-remote-testpy: hash bytes explicitly
  svn-fe: allow svnrdump_sim.py to run with Python 3
  git_remote_helpers: use 2to3 if building with Python 3
  git_remote_helpers: force rebuild if python version changes
  git_remote_helpers: fix input when running under Python 3
  git_remote_helpers: allow building with Python 3

Merge branch 'pw/git-p4-on-cygwin'

Improve "git p4" on Cygwin.

* pw/git-p4-on-cygwin: (21 commits)
  git p4: introduce gitConfigBool
  git p4: avoid shell when calling git config
  git p4: avoid shell when invoking git config --get-all
  git p4: avoid shell when invoking git rev-list
  git p4: avoid shell when mapping users
  git p4: disable read-only attribute before deleting
  git p4 test: use test_chmod for cygwin
  git p4: cygwin p4 client does not mark read-only
  git p4 test: avoid wildcard * in windows
  git p4 test: use LineEnd unix in windows tests too
  git p4 test: newline handling
  git p4: scrub crlf for utf16 files on windows
  git p4: remove unreachable windows \r\n conversion code
  git p4 test: translate windows paths for cygwin
  git p4 test: start p4d inside its db dir
  git p4 test: use client_view in t9806
  git p4 test: avoid loop in client_view
  git p4 test: use client_view to build the initial client
  git p4: generate better error message for bad depot path
  git p4: remove unused imports
  ...

Merge branch 'jk/read-commit-buffer-data-after-free'

Clarify the ownership rule for commit->buffer field, which some
callers incorrectly accessed without making sure it is populated.

* jk/read-commit-buffer-data-after-free:
  logmsg_reencode: lazily load missing commit buffers
  logmsg_reencode: never return NULL
  commit: drop useless xstrdup of commit message

Merge branch 'mm/add-u-A-sans-pathspec'

Forbid "git add -u" and "git add -A" without pathspec run from a
subdirectory, to train people to type "." (or ":/") to make the
choice of default does not matter.

* mm/add-u-A-sans-pathspec:
  add: warn when -u or -A is used without pathspec

Merge branch 'jc/push-reject-reasons'

Improve error and advice messages given locally when "git push"
refuses when it cannot compute fast-forwardness by separating these
cases from the normal "not a fast-forward; merge first and push
again" case.

* jc/push-reject-reasons:
  push: finishing touches to explain REJECT_ALREADY_EXISTS better
  push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
  push: further simplify the logic to assign rejection reason
  push: further clean up fields of "struct ref"

Merge branch 'jk/config-parsing-cleanup'

Configuration parsing for tar.* configuration variables were
broken. Introduce a new config-keyname parser API to make the
callers much less error prone.

* jk/config-parsing-cleanup:
  reflog: use parse_config_key in config callback
  help: use parse_config_key for man config
  submodule: simplify memory handling in config parsing
  submodule: use parse_config_key when parsing config
  userdiff: drop parse_driver function
  convert some config callbacks to parse_config_key
  archive-tar: use parse_config_key when parsing config
  config: add helper function for parsing key names

Merge branch 'jc/custom-comment-char'

Allow a configuration variable core.commentchar to customize the
character used to comment out the hint lines in the edited text from
the default '#'.

* jc/custom-comment-char:
  Allow custom "comment char"

Start preparing for 1.8.1.3

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

Merge branch 'bc/git-p4-for-python-2.4' into maint

* bc/git-p4-for-python-2.4:
  INSTALL: git-p4 does not support Python 3
  git-p4.py: support Python 2.4
  git-p4.py: support Python 2.5

Merge branch 'nd/edit-branch-desc-while-detached' into maint

Attempt to "branch --edit-description" an existing branch, while
being on a detached HEAD, errored out.

* nd/edit-branch-desc-while-detached:
  branch: no detached HEAD check when editing another branch's description

Merge branch 'jn/do-not-drop-username-when-reading-from-etc-mailname' into maint

We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug lost
the "user@" part.

* jn/do-not-drop-username-when-reading-from-etc-mailname:
  ident: do not drop username when reading from /etc/mailname

Merge branch 'jk/cvsimport-does-not-work-with-cvsps3' into maint

* jk/cvsimport-does-not-work-with-cvsps3:
  git-cvsimport.txt: cvsps-2 is deprecated

Merge branch 'dl/am-hg-locale' into maint

"git am" did not parse datestamp correctly from Hg generated patch,
when it is run in a locale outside C (or en)

* dl/am-hg-locale:
  am: invoke perl's strftime in C locale

Merge branch 'jc/help' into maint

* jc/help:
  help: include <common-cmds.h> only in one file

Merge branch 'jc/merge-blobs' into maint

* jc/merge-blobs:
  Makefile: Replace merge-file.h with merge-blobs.h in LIB_H
  merge-tree: fix d/f conflicts
  merge-tree: add comments to clarify what these functions are doing
  merge-tree: lose unused "resolve_directories"
  merge-tree: lose unused "flags" from merge_list
  Which merge_file() function do you mean?

Merge branch 'jc/doc-maintainer' into maint

* jc/doc-maintainer:
  howto/maintain: document "### match next" convention in jch/pu branch
  howto/maintain: mark titles for asciidoc
  Documentation: update "howto maintain git"

Merge branch 'bc/fix-array-syntax-for-3.0-in-completion-bash' into maint

Command line completion code was inadvertently made incompatible with
older versions of bash by using a newer array notation.

* bc/fix-array-syntax-for-3.0-in-completion-bash:
  git-completion.bash: replace zsh notation that breaks bash 3.X

Update draft release notes to 1.8.2

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

Merge branch 'nd/edit-branch-desc-while-detached'

Attempt to "branch --edit-description" an existing branch, while
being on a detached HEAD, errored out.

* nd/edit-branch-desc-while-detached:
  branch: no detached HEAD check when editing another branch's description

Merge branch 'jk/gc-auto-after-fetch'

Help "fetch only" repositories that do not trigger "gc --auto"
often enough.

* jk/gc-auto-after-fetch:
  fetch-pack: avoid repeatedly re-scanning pack directory
  fetch: run gc --auto after fetching

Merge branch 'bc/git-p4-for-python-2.4'

With small updates to remove dependency on newer features of
Python, keep git-p4 usable with older Python.

* bc/git-p4-for-python-2.4:
  INSTALL: git-p4 does not support Python 3
  git-p4.py: support Python 2.4
  git-p4.py: support Python 2.5

Merge branch 'jn/do-not-drop-username-when-reading-from-etc-mailname'

We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part.  This is to fix it.

* jn/do-not-drop-username-when-reading-from-etc-mailname:
  ident: do not drop username when reading from /etc/mailname

Merge branch 'jk/cvsimport-does-not-work-with-cvsps3'

Warn people that other tools are more recommendable over
cvsimport+cvsps2 combo when doing a one-shot import, and cvsimport
will not work with cvsps3.

* jk/cvsimport-does-not-work-with-cvsps3:
  git-cvsimport.txt: cvsps-2 is deprecated

Merge branch 'jc/do-not-let-random-file-interfere-with-completion-tests'

Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.

* jc/do-not-let-random-file-interfere-with-completion-tests:
  t9902: protect test from stray build artifacts

Merge branch 'as/test-cleanup'

* as/test-cleanup:
  t7102 (reset): don't hardcode SHA-1 in expected outputs

Merge branch 'jc/no-git-config-in-clone'

We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.

* jc/no-git-config-in-clone:
  clone: do not export and unexport GIT_CONFIG

Merge branch 'nd/fetch-depth-is-broken'

"git fetch --depth" was broken in at least three ways.  The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.

* nd/fetch-depth-is-broken:
  fetch: elaborate --depth action
  upload-pack: fix off-by-one depth calculation in shallow clone
  fetch: add --unshallow for turning shallow repo into complete one

Merge git://ozlabs.org/~paulus/gitk

* git://ozlabs.org/~paulus/gitk:
  gitk: Ignore gitk-wish buildproduct

git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"

fadf8c7 (git_remote_helpers: force rebuild if python version changes, 2013-01-20)
started using a marker file to keep track of the version of Python interpreter
used for the last build, but forgot to remove it when asked to "make clean".

Acked-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

INSTALL: git-p4 does not support Python 3

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

branch: no detached HEAD check when editing another branch's description

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'rr/minimal-stat'

Some reimplementations of Git does not write all the stat info back
to the index due to their implementation limitations (e.g. jgit
running on Java).  A configuration option can tell Git to ignore
changes to most of the stat fields and only pay attention to mtime
and size, which these implementations can reliably update.  This
avoids excessive revalidation of contents.

* rr/minimal-stat:
  Enable minimal stat checking

Merge branch 'nd/magic-pathspec-from-root'

When giving arguments without "--" disambiguation, object names
that come  earlier on the command line must not be interpretable as
pathspecs and pathspecs that come later on the command line must
not be interpretable as object names.  Tweak the disambiguation
rule so that ":/" (no other string before or after) is always
interpreted as a pathspec, to avoid having to say "git cmd -- :/".

* nd/magic-pathspec-from-root:
  grep: avoid accepting ambiguous revision
  Update :/abc ambiguity check

Merge branch 'maint'

* maint:
  README: update stale and/or incorrect information

Merge branch 'tb/t0050-maint' into maint

Update tests that were expecting to fail due to a bug that was
fixed earlier.

* tb/t0050-maint:
  t0050: Use TAB for indentation
  t0050: honor CASE_INSENSITIVE_FS in add (with different case)
  t0050: known breakage vanished in merge (case change)

gitk: Ignore gitk-wish buildproduct

gitk, when bound into the git.git project tree, used to live at the
root level, but in 62ba514 (Move gitk to its own subdirectory,
2007-11-17) it was moved to a subdirectory.  The code used to track
changes to TCLTK_PATH (which should cause gitk to be rebuilt to
point at the new interpreter) was left in the main Makefile instead
of being moved to the new Makefile that was created for the gitk
project.

Also add .gitignore file to list build artifacts for the gitk
project.

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

Merge branch 'nd/fix-directory-attrs-off-by-one' into maint

The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does.  The initial implementation of this that was
merged to 'maint' and 1.8.1.1 had severe performance degradations.

* nd/fix-directory-attrs-off-by-one:
  attr: avoid calling find_basename() twice per path
  attr: fix off-by-one directory component length calculation

Merge branch 'ph/rebase-preserve-all-merges' into maint

"git rebase --preserve-merges" lost empty merges in recent versions
of Git.

* ph/rebase-preserve-all-merges:
  rebase --preserve-merges: keep all merge commits including empty ones

README: update stale and/or incorrect information

Ramkumar Ramachandra noticed that the old address for the marc
archive no longer works.  Update it to its marc.info address,
and also refer to the gmane site.

Remove the reference to "note from the maintainer", which is not
usually followed by any useful discussion on status, direction nor
tasks.

Also replace the reference to "What's in git.git" with "What's
cooking".

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

Update draft release notes to 1.8.2

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

Sync with 1.8.1.2

Git 1.8.1.2

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

Merge branch 'ss/help-htmlpath-config-doc' into maint

* ss/help-htmlpath-config-doc:
  config.txt: Document help.htmlpath config parameter

Merge branch 'nd/attr-debug-fix' into maint

* nd/attr-debug-fix:
  attr: make it build with DEBUG_ATTR again

Merge branch 'ds/completion-silence-in-tree-path-probe' into maint

* ds/completion-silence-in-tree-path-probe:
  git-completion.bash: silence "not a valid object" errors

Merge branch 'jn/maint-trim-vim-contrib' into maint

* jn/maint-trim-vim-contrib:
  contrib/vim: simplify instructions for old vim support

Merge branch 'pe/doc-email-env-is-trumped-by-config' into maint

* pe/doc-email-env-is-trumped-by-config:
  git-commit-tree(1): correct description of defaults

Merge branch 'mk/complete-tcsh' into maint

Command line completion for "tcsh" emitted an unwanted space
after completing a single directory name.

* mk/complete-tcsh:
  Prevent space after directories in tcsh completion

Merge branch 'ap/status-ignored-in-ignored-directory' into maint

Output from "git status --ignored" did not work well when used with
"--untracked".

* ap/status-ignored-in-ignored-directory:
  status: always report ignored tracked directories
  git-status: Test --ignored behavior
  dir.c: Make git-status --ignored more consistent

Merge branch 'er/stop-recommending-parsecvs' into maint

* er/stop-recommending-parsecvs:
  Remove the suggestion to use parsecvs, which is currently broken.

Merge branch 'mh/ceiling' into maint

An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.

* mh/ceiling:
  string_list_longest_prefix(): remove function
  setup_git_directory_gently_1(): resolve symlinks in ceiling paths
  longest_ancestor_length(): require prefix list entries to be normalized
  longest_ancestor_length(): take a string_list argument for prefixes
  longest_ancestor_length(): use string_list_split()
  Introduce new function real_path_if_valid()
  real_path_internal(): add comment explaining use of cwd
  Introduce new static function real_path_internal()

Merge branch 'tb/t0050-maint'

Update tests that were expecting to fail due to a bug that was
fixed earlier.

* tb/t0050-maint:
  t0050: Use TAB for indentation
  t0050: honor CASE_INSENSITIVE_FS in add (with different case)
  t0050: known breakage vanished in merge (case change)

Merge branch 'dl/am-hg-locale'

Datestamp recorded in "Hg" format patch was reformatted incorrectly
to an e-mail looking date using locale dependant strftime, causing
patch application to fail.

* dl/am-hg-locale:
  am: invoke perl's strftime in C locale

Merge branch 'jc/help'

A header file that has the definition of a static array was
included in two places, wasting the space.

* jc/help:
  help: include <common-cmds.h> only in one file

Merge branch 'bc/fix-array-syntax-for-3.0-in-completion-bash'

Fix use of an array notation that older versions of bash do not
understand.

* bc/fix-array-syntax-for-3.0-in-completion-bash:
  git-completion.bash: replace zsh notation that breaks bash 3.X

add: warn when -u or -A is used without pathspec

Most Git commands that can be used with or without pathspec operate
tree-wide by default, the pathspec being used to restrict their
scope.  A few exceptions are: 'git grep', 'git clean', 'git add -u'
and 'git add -A'.  When run in a subdirectory without pathspec, they
operate only on paths in the current directory.

The inconsistency of 'git add -u' and 'git add -A' is particularly
problematic since other 'git add' subcommands (namely 'git add -p'
and 'git add -e') are tree-wide by default.  It also means that "git
add -u && git commit" will record a state that is different from
what is recorded with "git commit -a".

Flipping the default now is unacceptable, so let's start training
users to type 'git add -u|-A :/' or 'git add -u|-A .' explicitly, to
prepare for the next steps:

* forbid 'git add -u|-A' without pathspec (like 'git add' without
  option)

* much later, maybe, re-allow 'git add -u|-A' without pathspec, that
  will add all tracked and modified files, or all files, tree-wide.

A nice side effect of this patch is that it makes the :/ magic
pathspec easier to discover for users.

When the command is called from the root of the tree, there is no
ambiguity and no need to change the behavior, hence no need to warn.

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

git-remote-testpy: fix path hashing on Python 3

When this change was originally made (0846b0c - git-remote-testpy:
hash bytes explicitly , I didn't realise that the "hex" encoding we
chose is a "bytes to bytes" encoding so it just fails with an error
on Python 3 in the same way as the original code.

It is not possible to provide a single code path that works on
Python 2 and Python 3 since Python 2.x will attempt to decode the
string before encoding it, which fails for strings that are not
valid in the default encoding.  Python 3.1 introduced the
"surrogateescape" error handler which handles this correctly and
permits a bytes -> unicode -> bytes round-trip to be lossless.  As
the original came from reading the filesystem path, we convert them
back into the original bytes encoded in sys.getfilesystemencoding().

At this point Python 3.0 is unsupported so we don't go out of our
way to try to support it.

Helped-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: introduce gitConfigBool

Make the intent of "--bool" more obvious by returning a direct True
or False value.  Convert a couple non-bool users with obvious bool
intent.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: avoid shell when calling git config

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: avoid shell when invoking git config --get-all

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: avoid shell when invoking git rev-list

Invoke git rev-list directly, avoiding the shell, in
P4Submit and P4Sync.  The overhead of starting extra
processes is significant in cygwin; this speeds things
up on that platform.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: avoid shell when mapping users

The extra quoting and double-% are unneeded, just to work
around the shell.  Instead, avoid the shell indirection.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: disable read-only attribute before deleting

On windows, p4 marks un-edited files as read-only.  Not only are
they read-only, but also they cannot be deleted.  Remove the
read-only attribute before deleting in both the copy and rename
cases.

This also happens in the RCS cleanup code, where a file is marked
to be deleted, but must first be edited to remove adjust the
keyword lines.  Make sure it is editable before patching.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4 test: use test_chmod for cygwin

This test does a commit that is a pure mode change, submits
it to p4 but causes the submit to fail.  It verifies that
the state in p4 as well as the client directory are both
unmodified after the failed submit.

On cygwin, "chmod +x" does nothing, so use the test_chmod
function to modify the index directly too.

Also on cygwin, the executable bit cannot be seen in the
filesystem, so avoid that part of the test.  The checks of
p4 state are still valid, though.

Thanks-to: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: cygwin p4 client does not mark read-only

There are some old versions of p4, compiled for cygwin, that
treat read-only files differently.

Normally, a file that is not open is read-only, meaning that
"test -w" on the file is false.  This works on unix, and it works
on windows using the NT version of p4.  The cygwin version
of p4, though, changes the permissions, but does not set the
windows read-only attribute, so "test -w" returns false.

Notice this oddity and make the tests work, even on cygiwn.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4 test: avoid wildcard * in windows

This character is not valid in windows filenames, even though
it can appear in p4 depot paths.  Avoid using it in tests on
windows, both mingw and cygwin.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4 test: use LineEnd unix in windows tests too

In all clients, even those created on windows, use unix line
endings.  This makes it possible to verify file contents without
doing OS-specific comparisons in all the tests.

Tests in t9802-git-p4-filetype.sh are used to make sure that
the other LineEnd options continue to work.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4 test: newline handling

P4 stores newlines in the depos as \n.  By default, git does this
too, both on unix and windows.  Test to make sure that this stays
true.

Both git and p4 have mechanisms to use \r\n in the working
directory.  Exercise these.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: scrub crlf for utf16 files on windows

Files of type utf16 are handled with "p4 print" instead of the
normal "p4 -G print" interface due to how the latter does not
produce correct output.  See 55aa571 (git-p4: handle utf16
filetype properly, 2011-09-17) for details.

On windows, though, "p4 print" can not be told which line
endings to use, as there is no underlying client, and always
chooses crlf, even for utf16 files.  Convert the \r\n into \n
when importing utf16 files.

The fix for this is complex, in that the problem is a property
of the NT version of p4.  There are old versions of p4 that
were compiled directly for cygwin that should not be subjected
to text replacement.  The right check here, then, is to look
at the p4 version, not the OS version.  Note also that on cygwin,
platform.system() is "CYGWIN_NT-5.1" or similar, not "Windows".

Add a function to memoize the p4 version string and use it to
check for "/NT", indicating the Windows build of p4.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: remove unreachable windows \r\n conversion code

Replacing \r\n with \n on windows was added in c1f9197 (Replace
\r\n with \n when importing from p4 on Windows, 2007-05-24), to
work around an oddity with "p4 print" on windows.  Text files
are printed with "\r\r\n" endings, regardless of whether they
were created on unix or windows, and regardless of the client
LineEnd setting.

As of d2c6dd3 (use p4CmdList() to get file contents in Python
dicts. This is more robust., 2007-05-23), git-p4 uses "p4 -G
print", which generates files in a raw format.  As the native
line ending format if p4 is \n, there will be no \r\n in the
raw text.

Actually, it is possible to generate a text file so that the
p4 representation includes embedded \r\n, even though this is not
normal on either windows or unix.  In that case the code would
have mistakenly stripped them out, but now they will be left
intact.

More information on how p4 deals with line endings is here:

    http://kb.perforce.com/article/63

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4 test: translate windows paths for cygwin

Native windows binaries do not understand posix-like
path mapping offered by cygwin.  Convert paths to native
using "cygpath --windows" before presenting them to p4d.

This is done using the AltRoots mechanism of p4.  Both the
posix and windows forms are put in the client specification,
allowing p4 to find its location by native path even though
the environment reports a different PWD.

Shell operations in tests will use the normal form of $cli,
which will look like a posix path in cygwin, while p4 will
use AltRoots to match against the windows form of the working
directory.

This mechanism also handles the symlink issue that was fixed in
23bd0c9 (git p4 test: use real_path to resolve p4 client
symlinks, 2012-06-27).  Now that every p4 client view has
an AltRoots with the real_path in it, explicitly calculating
the real_path elsewhere is not necessary.

Thanks-to: Sebastian Schuberth <sschuberth@gmail.com>
Thanks-to: Johannes Sixt <j6t@kdbg.org>

fixup! git p4 test: translate windows paths for cygwin

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4 test: start p4d inside its db dir

This will avoid having to do native path conversion for
windows.  Also may be a bit cleaner always to know that p4d
has that working directory, instead of wherever the function
was called from.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4 test: use client_view in t9806

Use the standard client_view function from lib-git-p4.sh
instead of building one by hand.  This requires a bit of
rework, using the current value of $P4CLIENT for the client
name.  It also reorganizes the test to isolate changes to
$P4CLIENT and $cli in a subshell.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4 test: avoid loop in client_view

The printf command re-interprets the format string as
long as there are arguments to consume.  Use this to
simplify a for loop in the client_view() library function.

This requires a fix to one of the client_view callers.
An errant \n in the string was converted into a harmless
newline in the input to "p4 client -i", but now shows up
as a literal \n as passed through by "%s".  Remove the \n.

Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4 test: use client_view to build the initial client

Simplify the code a bit by using an existing function.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: generate better error message for bad depot path

Depot paths must start with //.  Exit with a better explanation
when a bad depot path is supplied.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: remove unused imports

Found by "pyflakes" checker tool.
Modules shelve, getopt were unused.
Module os.path is exported by os.
Reformat one-per-line as is PEP008 suggested style.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git p4: temp branch name should use / even on windows

Commit fed2369 (git-p4: Search for parent commit on branch creation,
2012-01-25) uses temporary branches to help find the parent of a
new p4 branch.  The temp branches are of the form "git-p4-tmp/%d"
for some p4 change number.  Mistakenly, this string was made
using os.path.join() instead of just string concatenation.  On
windows, this turns into a backslash (\), which is not allowed in
git branch names.

Reported-by: Casey McGinty <casey.mcginty@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jk/maint-gc-auto-after-fetch' into jk/gc-auto-after-fetch

* jk/maint-gc-auto-after-fetch:
  fetch-pack: avoid repeatedly re-scanning pack directory
  fetch: run gc --auto after fetching

fetch-pack: avoid repeatedly re-scanning pack directory

When we look up a sha1 object for reading via parse_object() =>
read_sha1_file() => read_object() callpath, we first check
packfiles, and then loose objects. If we still haven't found it, we
re-scan the list of packfiles in `objects/pack`. This final step
ensures that we can co-exist with a simultaneous repack process
which creates a new pack and then prunes the old object.

This extra re-scan usually does not have a performance impact for
two reasons:

  1. If an object is missing, then typically the re-scan will find a
     new pack, then no more misses will occur.  Or if it truly is
     missing, then our next step is usually to die().

  2. Re-scanning is cheap enough that we do not even notice.

However, these do not always hold. The assumption in (1) is that the
caller is expecting to find the object. This is usually the case,
but the call to `parse_object` in `everything_local` does not follow
this pattern. It is looking to see whether we have objects that the
remote side is advertising, not something we expect to
have. Therefore if we are fetching from a remote which has many refs
pointing to objects we do not have, we may end up re-scanning the
pack directory many times.

Even with this extra re-scanning, the impact is often not noticeable
due to (2); we just readdir() the packs directory and skip any packs
that are already loaded. However, if there are a large number of
packs, even enumerating the directory can be expensive, especially
if we do it repeatedly.

Having this many packs is a good sign the user should run `git gc`,
but it would still be nice to avoid having to scan the directory at
all.

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

fetch: run gc --auto after fetching

We generally try to run "gc --auto" after any commands that
might introduce a large number of new objects. An obvious
place to do so is after running "fetch", which may introduce
new loose objects or packs (depending on the size of the
fetch).

While an active developer repository will probably
eventually trigger a "gc --auto" on another action (e.g.,
git-rebase), there are two good reasons why it is nicer to
do it at fetch time:

  1. Read-only repositories which track an upstream (e.g., a
     continuous integration server which fetches and builds,
     but never makes new commits) will accrue loose objects
     and small packs, but never coalesce them into a more
     efficient larger pack.

  2. Fetching is often already perceived to be slow to the
     user, since they have to wait on the network. It's much
     more pleasant to include a potentially slow auto-gc as
     part of the already-long network fetch than in the
     middle of productive work with git-rebase or similar.

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

git-p4.py: support Python 2.4

Python 2.4 lacks the following features:

   subprocess.check_call
   struct.pack_into

Take a cue from 460d1026 and provide an implementation of the
CalledProcessError exception.  Then replace the calls to
subproccess.check_call with calls to subprocess.call that check the return
status and raise a CalledProcessError exception if necessary.

The struct.pack_into in t/9802 can be converted into a single struct.pack
call which is available in Python 2.4.

Signed-off-by: Brandon Casey <bcasey@nvidia.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4.py: support Python 2.5

Python 2.5 and older do not accept None as the first argument to
translate() and complain with:

   TypeError: expected a character buffer object

As suggested by Pete Wyckoff, let's just replace the call to translate()
with a regex search which should be more clear and more portable.

This allows git-p4 to be used with Python 2.5.

Signed-off-by: Brandon Casey <bcasey@nvidia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

logmsg_reencode: lazily load missing commit buffers

Usually a commit that makes it to logmsg_reencode will have
been parsed, and the commit->buffer struct member will be
valid. However, some code paths will free commit buffers
after having used them (for example, the log traversal
machinery will do so to keep memory usage down).

Most of the time this is fine; log should only show a commit
once, and then exits. However, there are some code paths
where this does not work. At least two are known:

  1. A commit may be shown as part of a regular ref, and
     then it may be shown again as part of a submodule diff
     (e.g., if a repo contains refs to both the superproject
     and subproject).

  2. A notes-cache commit may be shown during "log --all",
     and then later used to access a textconv cache during a
     diff.

Lazily loading in logmsg_reencode does not necessarily catch
all such cases, but it should catch most of them. Users of
the commit buffer tend to be either parsing for structure
(in which they will call parse_commit, and either we will
already have parsed, or we will load commit->buffer lazily
there), or outputting (either to the user, or fetching a
part of the commit message via format_commit_message). In
the latter case, we should always be using logmsg_reencode
anyway (and typically we do so via the pretty-print
machinery).

If there are any cases that this misses, we can fix them up
to use logmsg_reencode (or handle them on a case-by-case
basis if that is inappropriate).

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

logmsg_reencode: never return NULL

The logmsg_reencode function will return the reencoded
commit buffer, or NULL if reencoding failed or no reencoding
was necessary. Since every caller then ends up checking for NULL
and just using the commit's original buffer, anyway, we can
be a bit more helpful and just return that buffer when we
would have returned NULL.

Since the resulting string may or may not need to be freed,
we introduce a logmsg_free, which checks whether the buffer
came from the commit object or not (callers either
implemented the same check already, or kept two separate
pointers, one to mark the buffer to be used, and one for the
to-be-freed string).

Pushing this logic into logmsg_* simplifies the callers, and
will let future patches lazily load the commit buffer in a
single place.

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

commit: drop useless xstrdup of commit message

When git-commit is asked to reuse a commit message via "-c",
we call read_commit_message, which looks up the commit and
hands back either the re-encoded result, or a copy of the
original. We make a copy in the latter case so that the
ownership semantics of the return value are clear (in either
case, it can be freed).

However, since we return a "const char *", and since the
resulting buffer's lifetime is the same as that of the whole
program, we never bother to free it at all.

Let's just drop the copy. That saves us a copy in the common
case. While it does mean we leak in the re-encode case, it
doesn't matter, since we are relying on program exit to free
the memory anyway.

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

Merge branch 'for-junio' of git://bogomips.org/git-svn

* 'for-junio' of git://bogomips.org/git-svn:
  git-svn: Simplify calculation of GIT_DIR
  git-svn: cleanup sprintf usage for uppercasing hex

Update draft release notes to 1.8.2

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

Merge branch 'nd/retire-fnmatch'

Replace our use of fnmatch(3) with a more feature-rich wildmatch.
A handful patches at the bottom have been moved to nd/wildmatch to
graduate as part of that branch, before this series solidifies.

We may want to mark USE_WILDMATCH as an experimental curiosity a
bit more clearly (i.e. should not be enabled in production
environment, because it will make the behaviour between builds
unpredictable).

* nd/retire-fnmatch:
  Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
  wildmatch: advance faster in <asterisk> + <literal> patterns
  wildmatch: make a special case for "*/" with FNM_PATHNAME
  test-wildmatch: add "perf" command to compare wildmatch and fnmatch
  wildmatch: support "no FNM_PATHNAME" mode
  wildmatch: make dowild() take arbitrary flags
  wildmatch: rename constants and update prototype

Merge branch 'jc/doc-maintainer'

Describe tools for automation that were invented since this
document was originally written.

* jc/doc-maintainer:
  howto/maintain: document "### match next" convention in jch/pu branch
  howto/maintain: mark titles for asciidoc
  Documentation: update "howto maintain git"

howto/maintain: document "### match next" convention in jch/pu branch

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

ident: do not drop username when reading from /etc/mailname

An earlier conversion from fgets() to strbuf_getline() in the
codepath to read from /etc/mailname to learn the default host-part
of the ident e-mail address forgot that strbuf_getline() stores the
line at the beginning of the buffer just like fgets().

The "username@" the caller has prepared in the strbuf, expecting the
function to append the host-part to it, was lost because of this.

Reported-by: Mihai Rusu <dizzy@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: finishing touches to explain REJECT_ALREADY_EXISTS better

Now that "already exists" errors are given only when a push tries to
update an existing ref in refs/tags/ hierarchy, we can say "the
tag", instead of "the destination reference", and that is far easier
to understand.

Pointed out by Chris Rorvick.

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

git-remote-testpy: call print as a function

This is harmless in Python 2, which sees the parentheses as redundant
grouping, but is required for Python 3.  Since this is the only change
required to make this script just run under Python 3 without needing
2to3 it seems worthwhile.

The case of an empty print must be handled specially because in that
case Python 2 will interpret '()' as an empty tuple and print it as
'()'; inserting an empty string fixes this.

Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote-testpy: don't do unbuffered text I/O

Python 3 forbids unbuffered I/O in text mode.  Change the reading of
stdin in git-remote-testpy so that we read the lines as bytes and then
decode them a line at a time.

This allows us to keep the I/O unbuffered in order to avoid
reintroducing the bug fixed by commit 7fb8e16 (git-remote-testgit: fix
race when spawning fast-import).

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote-testpy: hash bytes explicitly

Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string.  Explicitly encode the argument to this method to hex
bytes so that we don't need to worry about failures to encode that might
occur if we chose a textual encoding.

This changes the directory used by git-remote-testpy for its git mirror
of the remote repository, but this tool should not have any serious
users as it is used primarily to test the Python remote helper
framework.

The use of encode() moves the required Python version forward to 2.0.

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

svn-fe: allow svnrdump_sim.py to run with Python 3

The changes to allow this script to run with Python 3 are minimal and do
not affect its functionality on the versions of Python 2 that are
already supported (2.4 onwards).

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git_remote_helpers: use 2to3 if building with Python 3

Using the approach detailed in the Python documentation[1], run 2to3 on
the code as part of the build if building with Python 3.

The code itself requires no changes to convert cleanly.

[1] http://docs.python.org/3.3/howto/pyporting.html#during-installation

Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>