Merge branch 'sg/t6050-failing-editor-test-fix'

* sg/t6050-failing-editor-test-fix:
  t6050-replace: make failing editor test more robust

Merge branch 'ew/for-each-ref-doc'

* ew/for-each-ref-doc:
  for-each-ref: document `creatordate` and `creator` fields

Merge branch 'dw/signoff-doc'

The documentation has been updated to hint the connection between
the '--signoff' option and DCO.

* dw/signoff-doc:
  Expand documentation describing --signoff

Merge branch 'jk/clang-pedantic'

A few unportable C construct have been spotted by clang compiler
and have been fixed.

* jk/clang-pedantic:
  bswap: add NO_UNALIGNED_LOADS define
  avoid shifting signed integers 31 bits

Merge branch 'ew/send-email-mutt-alias-fix'

"git send-email" was confused by escaped quotes stored in the alias
files saved by "mutt", which has been corrected.

* ew/send-email-mutt-alias-fix:
  git-send-email: do not double-escape quotes from mutt

Merge branch 'ss/user-manual'

Drop a few old "todo" items by deciding that the change one of them
suggests is not such a good idea, and doing the change the other
one suggested to do.

* ss/user-manual:
  user-manual: add addition gitweb information
  user-manual: add section documenting shallow clones
  glossary: define the term shallow clone
  user-manual: remove temporary branch entry from todo list

Merge branch 'nd/clear-gitenv-upon-use-of-alias'

d95138e6 (setup: set env $GIT_WORK_TREE when work tree is set, like
$GIT_DIR, 2015-06-26) attempted to work around a glitch in alias
handling by overwriting GIT_WORK_TREE environment variable to
affect subprocesses when set_git_work_tree() gets called, which
resulted in a rather unpleasant regression to "clone" and "init".
Try to address the same issue by always restoring the environment
and respawning the real underlying command when handling alias.

* nd/clear-gitenv-upon-use-of-alias:
  run-command: don't warn on SIGPIPE deaths
  git.c: make sure we do not leak GIT_* to alias scripts
  setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..
  git.c: make it clear save_env() is for alias handling only

Merge branch 'nd/ita-cleanup'

Paths that have been told the index about with "add -N" are not
quite yet in the index, but a few commands behaved as if they
already are in a harmful way.

* nd/ita-cleanup:
  grep: make it clear i-t-a entries are ignored
  add and use a convenience macro ce_intent_to_add()
  blame: remove obsolete comment

Merge branch 'nd/dir-exclude-cleanup'

The "exclude_list" structure has the usual "alloc, nr" pair of
fields to be used by ALLOC_GROW(), but clear_exclude_list() forgot
to reset 'alloc' to 0 when it cleared 'nr'to discard the managed
array.

* nd/dir-exclude-cleanup:
  dir.c: clean the entire struct in clear_exclude_list()

Merge branch 'jk/pack-revindex'

In-core storage of the reverse index for .pack files (which lets
you go from a pack offset to an object name) has been streamlined.

* jk/pack-revindex:
  pack-revindex: store entries directly in packed_git
  pack-revindex: drop hash table

Merge branch 'mh/notes-allow-reading-treeish'

Some "git notes" operations, e.g. "git log --notes=<note>", should
be able to read notes from any tree-ish that is shaped like a notes
tree, but the notes infrastructure required that the argument must
be a ref under refs/notes/.  Loosen it to require a valid ref only
when the operation would update the notes (in which case we must
have a place to store the updated notes tree, iow, a ref).

* mh/notes-allow-reading-treeish:
  notes: allow treeish expressions as notes ref

Sync with maint

* maint:
  l10n: ko.po: Add Korean translation

First batch for post 2.7 cycle

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

Merge branch 'vl/grep-configurable-threads'

"git grep" can now be configured (or told from the command line)
how many threads to use when searching in the working tree files.

* vl/grep-configurable-threads:
  grep: add --threads=<num> option and grep.threads configuration
  grep: slight refactoring to the code that disables threading
  grep: allow threading even on a single-core machine

Merge branch 'ea/blame-progress'

"git blame" learned to produce the progress eye-candy when it takes
too much time before emitting the first line of the result.

* ea/blame-progress:
  blame: add support for --[no-]progress option

Merge branch 'sb/submodule-parallel-fetch'

Add a framework to spawn a group of processes in parallel, and use
it to run "git fetch --recurse-submodules" in parallel.

Rerolled and this seems to be a lot cleaner.  The merge of the
earlier one to 'next' has been reverted.

* sb/submodule-parallel-fetch:
  submodules: allow parallel fetching, add tests and documentation
  fetch_populated_submodules: use new parallel job processing
  run-command: add an asynchronous parallel child processor
  sigchain: add command to pop all common signals
  strbuf: add strbuf_read_once to read without blocking
  xread: poll on non blocking fds
  submodule.c: write "Fetching submodule <foo>" to stderr

Merge branch 'ps/push-delete-option'

"branch --delete" has "branch -d" but "push --delete" does not.

* ps/push-delete-option:
  push: add '-d' as shorthand for '--delete'
  push: add '--delete' flag to synopsis

Merge branch 'ep/make-phoney'

A slight update to the Makefile.

* ep/make-phoney:
  Makefile: add missing phony target

Merge branch 'nd/stop-setenv-work-tree'

An earlier change in 2.5.x-era broke users' hooks and aliases by
exporting GIT_WORK_TREE to point at the root of the working tree,
interfering when they tried to use a different working tree without
setting GIT_WORK_TREE environment themselves.

* nd/stop-setenv-work-tree:
  Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"

notes: allow treeish expressions as notes ref

init_notes() is the main point of entry to the notes API. It ensures
that the input can be used as ref, because it needs a ref to update to
store notes tree after modifying it.

There however are many use cases where notes tree is only read, e.g.
"git log --notes=...".  Any notes-shaped treeish could be used for such
purpose, but it is not allowed due to existing restriction.

Allow treeish expressions to be used in the case the notes tree is going
to be used without write "permissions".  Add a flag to distinguish
whether the notes tree is intended to be used read-only, or will be
updated.

With this change, operations that use notes read-only can be fed any
notes-shaped tree-ish can be used, e.g. git log --notes=notes@{1}.

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

Merge branch 'maint' of git://github.com/git-l10n/git-po into maint

* 'maint' of git://github.com/git-l10n/git-po:
  l10n: ko.po: Add Korean translation

Expand documentation describing --signoff

Modify various document (man page) files to explain
in more detail what --signoff means.

This was inspired by https://lwn.net/Articles/669976/ where
paulj noted, "adding [the] '-s' argument to [a] git commit
doesn't really mean you have even heard of the DCO...".
Extending git's documentation will make it easier to argue
that developers understood --signoff when they use it.

Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t6050-replace: make failing editor test more robust

'git replace --edit' should error out when the invoked editor fails,
but the test checking this behavior would not notice if this weren't
the case.

The test in question, ever since it was added in 85f98fc037ae
(replace: add tests for --edit, 2014-05-17), has simulated a failing
editor in an unconventional way:

  test_must_fail env GIT_EDITOR='./fakeeditor;false' git replace --edit

I presume the reason for this unconventional editor was the fact that
'git replace --edit' requires the edited object to be different from
the original, but a mere 'false' as editor would leave the object
unchanged and 'git replace --edit' would error out anyway complaining
about the new and the original object files being the same.  Running
'fakeeditor' before 'false' was supposed to ensure that the object
file is modified and thus 'git replace --edit' errors out because of
the failed editor.

However, this editor doesn't actually modify the edited object,
because start_command() turns this editor into:

  /bin/sh -c './fakeeditor;false "$@"' './fakeeditor;false' \
          '.../.git/REPLACE_EDITOBJ'

This means that the test's fakeeditor script doesn't even get the path
of the object to be edited as argument, triggering error messages from
the commands executed inside the script ('sed' and 'mv'), and
ultimately leaving the object file unchanged.

If a patch were to remove the die() from the error path after
launch_editor(), the test would not catch it, because 'git replace'
would continue execution past launch_editor() and would error out a
bit later due to the unchanged edited object.  Though 'git replace'
would error out for the wrong reason, this would satisfy
'test_must_fail' just as well, and the test would succeed leaving the
undesired change unnoticed.

Create a proper failing fake editor script for this test to ensure
that the edited object is in fact modified and 'git replace --edit'
won't error out because the new and original object files are the
same.

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

for-each-ref: document `creatordate` and `creator` fields

These were introduced back in 2006 at 3175aa1ec28c but
never documented.

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

Git 2.7

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

Sync with 2.6.5

Git 2.6.5

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

Merge branch 'jk/pending-keep-tag-name' into maint

History traversal with "git log --source" that starts with an
annotated tag failed to report the tag as "source", due to an
old regression in the command line parser back in v2.2 days.

* jk/pending-keep-tag-name:
  revision.c: propagate tag names from pending array

Merge branch 'jk/symbolic-ref-maint' into maint

"git symbolic-ref" forgot to report a failure with its exit status.

* jk/symbolic-ref-maint:
  t1401: test reflog creation for git-symbolic-ref
  symbolic-ref: propagate error code from create_symref()

Merge branch 'jk/ident-loosen-getpwuid' into maint

When getpwuid() on the system returned NULL (e.g. the user is not
in the /etc/passwd file or other uid-to-name mappings), the
codepath to find who the user is to record it in the reflog barfed
and died.  Loosen the check in this codepath, which already accepts
questionable ident string (e.g. host part of the e-mail address is
obviously bogus), and in general when we operate fmt_ident() function
in non-strict mode.

* jk/ident-loosen-getpwuid:
  ident: loosen getpwuid error in non-strict mode
  ident: keep a flag for bogus default_email
  ident: make xgetpwuid_self() a static local helper

Merge branch 'jk/send-email-ssl-errors' into maint

Improve error reporting when SMTP TLS fails.

* jk/send-email-ssl-errors:
  send-email: enable SSL level 1 debug output

Merge branch 'sg/completion-no-column' into maint

The completion script (in contrib/) used to list "git column"
(which is not an end-user facing command) as one of the choices

* sg/completion-no-column:
  completion: remove 'git column' from porcelain commands

git-send-email: do not double-escape quotes from mutt

mutt saves aliases with escaped quotes in the form of:

alias dot \"Dot U. Sir\" <somebody@example.org>

When we pass through our sanitize_address routine,
we end up with double-escaping:

 To: "\\\"Dot U. Sir\\\" <somebody@example.org>

Remove the escaping in mutt only for now, as I am not sure
if other mailers can do this or if this is better fixed in
sanitize_address.

Cc: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Cc: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bswap: add NO_UNALIGNED_LOADS define

The byte-swapping code automatically decides, based on the
platform, whether it is sensible to cast and do a potentially
unaligned ntohl(), or to pick individual bytes out of an
array.

It can be handy to override this decision, though, when
turning on compiler flags that will complain about unaligned
loads (such as -fsanitize=undefined). This patch adds a
macro check to make this possible.

There's no nice Makefile knob here; this is for prodding at
Git's internals, and anybody using it can set
"-DNO_UNALIGNED_LOADS" in the same place they are setting up
"-fsanitize".

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

avoid shifting signed integers 31 bits

We sometimes use 32-bit unsigned integers as bit-fields.
It's fine to access the MSB, because it's unsigned. However,
doing so as "1 << 31" is wrong, because the constant "1" is
a signed int, and we shift into the sign bit, causing
undefined behavior.

We can fix this by using "1U" as the constant.

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

l10n: ko.po: Add Korean translation

Signed-off-by: Changwoo Ryu <cwryu@debian.org>
Signed-off-by: Hyunjun Kim <yoloseem@users.noreply.github.com>

Merge tag 'l10n-2.7.0-rnd2+de' of git://github.com/git-l10n/git-po

l10n-2.7.0-rnd2+de

* tag 'l10n-2.7.0-rnd2+de' of git://github.com/git-l10n/git-po:
  l10n: de.po: translate 68 new messages
  l10n: de.po: improve some translations

user-manual: add addition gitweb information

Rework the section on gitweb to add information about the cgi script
and the instaweb command.

Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: add section documenting shallow clones

Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

glossary: define the term shallow clone

There are several places in the documentation that
the term shallow clone is used. Defining the term
enables its use elsewhere with a known definition.

Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

run-command: don't warn on SIGPIPE deaths

When git executes a sub-command, we print a warning if the
command dies due to a signal, but make an exception for
"uninteresting" cases like SIGINT and SIGQUIT (since the
user presumably just hit ^C).

We should make a similar exception for SIGPIPE, because it's
an expected and uninteresting return in most cases; it
generally means the user quit the pager before git had
finished generating all output.  This used to be very hard
to trigger in practice, because:

  1. We only complain if we see a real SIGPIPE death, not
     the shell-induced 141 exit code. This means that
     anything we run via the shell does not trigger the
     warning, which includes most non-trivial aliases.

  2. The common case for SIGPIPE is the user quitting the
     pager before git has finished generating all output.
     But if the user triggers a pager with "-p", we redirect
     the git wrapper's stderr to that pager, too.  Since the
     pager is dead, it means that the message goes nowhere.

  3. You can see it if you run your own pager, like
     "git foo | head". But that only happens if "foo" is a
     non-builtin (so it doesn't work with "log", for
     example).

However, it may become more common after 86d26f2, which
teaches alias to re-exec builtins rather than running them
in the same process. This case doesn't trigger (1), as we
don't need a shell to run a git command. It doesn't trigger
(2), because the pager is not started by the original git,
but by the inner re-exec of git. And it doesn't trigger (3),
because builtins are treated more like non-builtins in this
case.

Given how flaky this message already is (e.g., you cannot
even know whether you will see it, as git optimizes out some
shell invocations behind the scenes based on the contents of
the command!), and that it is unlikely to ever provide
useful information, let's suppress it for all cases of
SIGPIPE.

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

l10n: de.po: translate 68 new messages

Translate 68 new messages came from git.pot update in
f4f2c8f (l10n: git.pot: v2.7.0 round 1 (66 new, 29 removed)) and
2c0ca05 (l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Matthias Rüster <matthias.ruester@gmail.com>

l10n: de.po: improve some translations

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Phillip Sz <phillip.szelat@gmail.com>

Git 2.7-rc3

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

Merge branch 'sh/p4-multi-depot'

"git p4" when interacting with multiple depots at the same time
used to incorrectly drop changes.

* sh/p4-multi-depot:
  git-p4: reduce number of server queries for fetches
  git-p4: support multiple depot paths in p4 submit
  git-p4: failing test case for skipping changes with multiple depots

Merge branch 'jk/pending-keep-tag-name'

History traversal with "git log --source" that starts with an
annotated tag failed to report the tag as "source", due to an
old regression in the command line parser back in v2.2 days.

* jk/pending-keep-tag-name:
  revision.c: propagate tag names from pending array

Merge branch 'jk/symbolic-ref-maint'

"git symbolic-ref" forgot to report a failure with its exit status.

* jk/symbolic-ref-maint:
  t1401: test reflog creation for git-symbolic-ref
  symbolic-ref: propagate error code from create_symref()

Merge tag 'l10n-2.7.0-rnd2' of git://github.com/git-l10n/git-po

l10n-2.7.0-rnd2

* tag 'l10n-2.7.0-rnd2' of git://github.com/git-l10n/git-po:
  l10n: ru.po: update Russian translation
  l10n: Updated Bulgarian translation of git (2477t,0f,0u)
  l10n: ca.po: update translation
  l10n: zh_CN: for git v2.7.0 l10n round 2
  l10n: sv.po: Update Swedish translation (2477t0f0u)
  l10n: sv: Fix bad translation
  l10n: fr.po v2.7.0 round 2 (2477t)
  l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)
  l10n: zh_CN: for git v2.7.0 l10n round 1
  l10n: ca.po: update translation
  l10n: fr v2.7.0 round 1 (2477t)
  l10n: Updated Bulgarian translation of git (2477t,0f,0u)
  l10n: sv.po: Update Swedish translation (2477t0f0u)
  l10n: vi.po: Updated translation (2477t)
  l10n: git.pot: v2.7.0 round 1 (66 new, 29 removed)
  l10n: fr.po: Fix typo
  l10n: fr.po: Fix typo

user-manual: remove temporary branch entry from todo list

In the section on "How to check out a different version of a
project" the "new" branch is used as a temporary branch.  A detached
HEAD was not used since it was a new feature introduced just a
couple weeks prior.

The section could be changed to use and explain a detached HEAD,
except that would increase the learning curve early in the manual.
Detached HEADs are discussed a couple sections later under
"Examining an old version without creating a new branch".

Let's declare that it is a bad idea to rewrite the example that
uses a temporary branch to do the sightseeing on a detached HEAD.

Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir.c: clean the entire struct in clear_exclude_list()

Make sure "el" can be reuseable again. The problem was el->alloc is
not cleared and may cause segfaults next time because add_exclude()
thinks el->excludes (being NULL) has enough space. Just clear the
entire struct to be safe.

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

grep: make it clear i-t-a entries are ignored

The expression "!S_ISREG(ce)" covers i-t-a entries as well because
ce->ce_mode would be zero then. I could make a comment saying that, but
it's probably better just to comment with code, in case i-t-a entry
content changes in future.

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

l10n: ru.po: update Russian translation

Signed-off-by: Dimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com>

Merge branch 'master' of git://github.com/alshopov/git-po

* 'master' of git://github.com/alshopov/git-po:
  l10n: Updated Bulgarian translation of git (2477t,0f,0u)

l10n: Updated Bulgarian translation of git (2477t,0f,0u)

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

l10n: ca.po: update translation

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>

l10n: zh_CN: for git v2.7.0 l10n round 2

Update 2 translations (2477t0f0u) for git v2.7.0-rc1.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge branch 'master' of git://github.com/nafmo/git-l10n-sv

* 'master' of git://github.com/nafmo/git-l10n-sv:
  l10n: sv.po: Update Swedish translation (2477t0f0u)
  l10n: sv: Fix bad translation

l10n: sv.po: Update Swedish translation (2477t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

l10n: sv: Fix bad translation

Found-by: Sebastian Rasmussen <sebras@gmail.com>
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

l10n: fr.po v2.7.0 round 2 (2477t)

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>

Git 2.7-rc2

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

Merge branch 'js/emu-write-epipe-on-windows'

The write(2) emulation for Windows learned to set errno to EPIPE
when necessary.

* js/emu-write-epipe-on-windows:
  mingw: emulate write(2) that fails with a EPIPE

push: don't mark options of recurse-submodules for translation

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.c: make sure we do not leak GIT_* to alias scripts

The unfortunate commit d95138e (setup: set env $GIT_WORK_TREE when
work tree is set, like $GIT_DIR - 2015-06-26) exposes another problem,
besides git-clone that's described in the previous commit. If
GIT_WORK_TREE (or even GIT_DIR) is exported to an alias script, it may
mislead git commands in the script where the repo is. Granted, most
scripts work on the repo where the alias is summoned from. But nowhere
do we forbid the script to visit another repository.

The revert of d95138e in the previous commit is sufficient as a
fix. However, to protect us from accidentally leaking GIT_*
environment variables again, we restore certain sensitive env before
calling the external script.

GIT_PREFIX is let through because there's another setup side effect
that we simply accepted so far: current working directory is
moved. Maybe in future we can introduce a new alias format that
guarantees no cwd move, then we can unexport GIT_PREFIX.

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

setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..

Commit d95138e [1] attempted to fix a .git file problem by
setting GIT_WORK_TREE whenever GIT_DIR is set. It sounded harmless
because we handle GIT_DIR and GIT_WORK_TREE side by side for most
commands, with two exceptions: git-init and git-clone.

"git clone" is not happy with d95138e. This command ignores GIT_DIR
but respects GIT_WORK_TREE [2] [3] which means it used to run fine
from a hook, where GIT_DIR was set but GIT_WORK_TREE was not (*).
With d95138e, GIT_WORK_TREE is set all the time and git-clone
interprets that as "I give you order to put the worktree here",
usually against the user's intention.

The solution in d95138e is reverted earlier, and instead we reuse
the solution from c056261 [4].  It fixed another setup-messed-
up-by-alias by saving and restoring env and spawning a new process,
but for git-clone and git-init only.

Now we conclude that setup-messed-up-by-alias is always evil. So the
env restoration is done for _all_ commands, including external ones,
whenever aliases are involved. It fixes what d95138e tried to fix,
without upsetting git-clone-inside-hooks.

The test from d95138e remains to verify it's not broken by this. A new
test is added to make sure git-clone-inside-hooks remains happy.

(*) GIT_WORK_TREE was not set _most of the time_. In some cases
    GIT_WORK_TREE is set and git-clone will behave differently. The
    use of GIT_WORK_TREE to direct git-clone to put work tree
    elsewhere looks like a mistake because it causes surprises this
    way. But that's a separate story.

[1] d95138e (setup: set env $GIT_WORK_TREE when work tree is set, like
             $GIT_DIR - 2015-06-26)
[2] 2beebd2 (clone: create intermediate directories of destination
             repo - 2008-06-25)
[3] 20ccef4 (make git-clone GIT_WORK_TREE aware - 2007-07-06)
[4] c056261 (git potty: restore environments after alias expansion -
             2014-06-08)

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

git.c: make it clear save_env() is for alias handling only

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

Merge branch 'nd/stop-setenv-work-tree' into nd/clear-gitenv-upon-use-of-alias

* nd/stop-setenv-work-tree:
  Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"

Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"

This reverts d95138e6 (setup: set env $GIT_WORK_TREE when work tree
is set, like $GIT_DIR, 2015-06-26).

It has caused three regression reports so far.

  http://article.gmane.org/gmane.comp.version-control.git/281608
  http://article.gmane.org/gmane.comp.version-control.git/281979
  http://article.gmane.org/gmane.comp.version-control.git/282691

All of them are about spawning git subprocesses, where the new
presence of GIT_WORK_TREE either changes command behaviour (git-init
or git-clone), or how repo/worktree is detected (from aliases), with
or without $GIT_DIR.

The original bug will be re-fixed another way.

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

l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)

Generate po/git.pot from v2.7.0-rc1-44-g1d88dab for git v2.7.0 l10n round 2.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge branch 'master' of git://github.com/git-l10n/git-po

* 'master' of git://github.com/git-l10n/git-po:
  l10n: zh_CN: for git v2.7.0 l10n round 1
  l10n: ca.po: update translation
  l10n: fr v2.7.0 round 1 (2477t)
  l10n: Updated Bulgarian translation of git (2477t,0f,0u)
  l10n: sv.po: Update Swedish translation (2477t0f0u)
  l10n: vi.po: Updated translation (2477t)
  l10n: git.pot: v2.7.0 round 1 (66 new, 29 removed)
  l10n: fr.po: Fix typo
  l10n: fr.po: Fix typo

pack-revindex: store entries directly in packed_git

A pack_revindex struct has two elements: the revindex
entries themselves, and a pointer to the packed_git. We need
both to do lookups, because only the latter knows things
like the number of objects in the pack.

Now that packed_git contains the pack_revindex struct it's
just as easy to pass around the packed_git itself, and we do
not need the extra back-pointer.

We can instead just store the entries directly in the pack.
All functions which took a pack_revindex now just take a
packed_git. We still lazy-load in find_pack_revindex, so
most callers are unaffected.

The exception is the bitmap code, which computes the
revindex and caches the pointer when we load the bitmaps. We
can continue to load, drop the extra cache pointer, and just
access bitmap_git.pack.revindex directly.

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

pack-revindex: drop hash table

The main entry point to the pack-revindex code is
find_pack_revindex(). This calls revindex_for_pack(), which
lazily computes and caches the revindex for the pack.

We store the cache in a very simple hash table. It's created
by init_pack_revindex(), which inserts an entry for every
packfile we know about, and we never grow or shrink the
hash. If we ever need the revindex for a pack that isn't in
the hash, we die() with an internal error.

This can lead to a race, because we may load more packs
after having called init_pack_revindex(). For example,
imagine we have one process which needs to look at the
revindex for a variety of objects (e.g., cat-file's
"%(objectsize:disk)" format).  Simultaneously, git-gc is
running, which is doing a `git repack -ad`. We might hit a
sequence like:

  1. We need the revidx for some packed object. We call
     find_pack_revindex() and end up in init_pack_revindex()
     to create the hash table for all packs we know about.

  2. We look up another object and can't find it, because
     the repack has removed the pack it's in. We re-scan the
     pack directory and find a new pack containing the
     object. It gets added to our packed_git list.

  3. We call find_pack_revindex() for the new object, which
     hits revindex_for_pack() for our new pack. It can't
     find the packed_git in the revindex hash, and dies.

You could also replace the `repack` above with a push or
fetch to create a new pack, though these are less likely
(you would have to somehow learn about the new objects to
look them up).

Prior to 1a6d8b9 (do not discard revindex when re-preparing
packfiles, 2014-01-15), this was safe, as we threw away the
revindex whenever we re-scanned the pack directory (and thus
re-created the revindex hash on the fly). However, we don't
want to simply revert that commit, as it was solving a
different race.

So we have a few options:

  - We can fix the race in 1a6d8b9 differently, by having
    the bitmap code look in the revindex hash instead of
    caching the pointer. But this would introduce a lot of
    extra hash lookups for common bitmap operations.

  - We could teach the revindex to dynamically add new packs
    to the hash table. This would perform the same, but
    would mean adding extra code to the revindex hash (which
    currently cannot be resized at all).

  - We can get rid of the hash table entirely. There is
    exactly one revindex per pack, so we can just store it
    in the packed_git struct. Since it's initialized lazily,
    it does not add to the startup cost.

    This is the best of both worlds: less code and fewer
    hash table lookups.  The original code likely avoided
    this in the name of encapsulation. But the packed_git
    and reverse_index code are fairly intimate already, so
    it's not much of a loss.

This patch implements the final option. It's a minimal
conversion that retains the pack_revindex struct. No callers
need to change, and we can do further cleanup in a follow-on
patch.

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

t1401: test reflog creation for git-symbolic-ref

The current code writes a reflog entry whenever we update a
symbolic ref, but we never test that this is so. Let's add a
test to make sure upcoming refactoring doesn't cause a
regression.

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

symbolic-ref: propagate error code from create_symref()

If create_symref() fails, git-symbolic-ref will still exit
with code 0, and our caller has no idea that the command did
nothing.

This appears to have been broken since the beginning of time
(e.g., it is not a regression where create_symref() stopped
calling die() or something similar).

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

git-p4: reduce number of server queries for fetches

When fetching changes from a depot using a full client spec, there
is no need to perform as many queries as there are top-level paths
in the client spec.  Instead we query all changes in chronological
order, also getting rid of the need to sort the results and remove
duplicates.

Signed-off-by: Sam Hocevar <sam@hocevar.net>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: support multiple depot paths in p4 submit

When submitting from a repository that was cloned using a client spec,
use the full list of paths when ruling out files that are outside the
view.  This fixes a bug where only files pertaining to the first path
would be included in the p4 submit.

Signed-off-by: Sam Hocevar <sam@hocevar.net>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update release notes to 2.7

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

Merge branch 'bc/format-patch-null-from-line'

"format-patch" has learned a new option to zero-out the commit
object name on the mbox "From " line.

* bc/format-patch-null-from-line:
  format-patch: check that header line has expected format
  format-patch: add an option to suppress commit hash
  sha1_file.c: introduce a null_oid constant

Merge branch 'jk/ident-loosen-getpwuid'

When getpwuid() on the system returned NULL (e.g. the user is not
in the /etc/passwd file or other uid-to-name mappings), the
codepath to find who the user is to record it in the reflog barfed
and died.  Loosen the check in this codepath, which already accepts
questionable ident string (e.g. host part of the e-mail address is
obviously bogus), and in general when we operate fmt_ident() function
in non-strict mode.

* jk/ident-loosen-getpwuid:
  ident: loosen getpwuid error in non-strict mode
  ident: keep a flag for bogus default_email
  ident: make xgetpwuid_self() a static local helper

Merge branch 'jk/send-email-ssl-errors'

Improve error reporting when SMTP TLS fails.

* jk/send-email-ssl-errors:
  send-email: enable SSL level 1 debug output

Merge branch 'sg/completion-no-column'

The completion script (in contrib/) used to list "git column"
(which is not an end-user facing command) as one of the choices

* sg/completion-no-column:
  completion: remove 'git column' from porcelain commands

Merge branch 'mc/push-recurse-submodules-config'

Add new config to avoid typing "--recurse-submodules" on each push.

* mc/push-recurse-submodules-config:
  push: follow the "last one wins" convention for --recurse-submodules
  push: test that --recurse-submodules on command line overrides config
  push: add recurseSubmodules config option

mingw: emulate write(2) that fails with a EPIPE

On Windows, when writing to a pipe fails, errno is always
EINVAL. However, Git expects it to be EPIPE.

According to the documentation, there are two cases in which write()
triggers EINVAL: the buffer is NULL, or the length is odd but the mode
is 16-bit Unicode (the broken pipe is not mentioned as possible cause).
Git never sets the file mode to anything but binary, therefore we know
that errno should actually be EPIPE if it is EINVAL and the buffer is
not NULL.

See https://msdn.microsoft.com/en-us/library/1570wh78.aspx for more
details.

This works around t5571.11 failing with v2.6.4 on Windows.

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

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

* git://ozlabs.org/~paulus/gitk:
  gitk: sv.po: Update Swedish translation (311t)
  gitk: Let .bleft.mid widgets 'breathe'
  gitk: Match ttk fonts to gitk fonts
  gitk: Update revision date in Japanese PO file
  gitk: Update "Language:" header
  gitk: Improve translation message
  gitk: Remove unused line
  gitk: Update year
  gitk: Change last translator line
  gitk: Update fuzzy messages
  gitk: Update Japanese translation
  gitk: Fix translation around copyright sign
  gitk: Update Japanese translation
  gitk: Fix wrong translation
  gitk: Translate Japanese catalog
  gitk: Translate more to Japanese catalog
  gitk: Update Japanese message catalog
  gitk: Re-sync line number in Japanese message catalogue
  gitk: Color name update

l10n: zh_CN: for git v2.7.0 l10n round 1

Update 66 translations (2477t0f0u) for git v2.7.0-rc0.

Reviewed-by: Ray Chen <oldsharp@gmail.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge branch 'master' of git://github.com/alexhenrie/git-po

* 'master' of git://github.com/alexhenrie/git-po:
  l10n: ca.po: update translation

Merge branch 'fr_v2.7.0' of git://github.com/jnavila/git

* 'fr_v2.7.0' of git://github.com/jnavila/git:
  l10n: fr v2.7.0 round 1 (2477t)

Merge branch 'master' of git://github.com/alshopov/git-po

* 'master' of git://github.com/alshopov/git-po:
  l10n: Updated Bulgarian translation of git (2477t,0f,0u)

l10n: ca.po: update translation

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>

Merge branch 'ja.po' of https://github.com/qykth-git/gitk

Merge branch 'color-fix' of https://github.com/qykth-git/gitk

l10n: fr v2.7.0 round 1 (2477t)

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>

l10n: Updated Bulgarian translation of git (2477t,0f,0u)

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

l10n: sv.po: Update Swedish translation (2477t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

revision.c: propagate tag names from pending array

When we unwrap a tag to find its commit for a traversal, we
do not propagate the "name" field of the tag in the pending
array (i.e., the ref name the user gave us in the first
place) to the commit (instead, we use an empty string). This
means that "git log --source" will never show the tag-name
for commits we reach through it.

This was broken in 2073949 (traverse_commit_list: support
pending blobs/trees with paths, 2014-10-15). That commit
tried to be careful and avoid propagating the path
information for a tag (which would be nonsensical) to trees
and blobs. But it should not have cut off the "name" field,
which should carry forward to children.

Note that this does mean that the "name" field will carry
forward to blobs and trees, too. Whereas prior to 2073949,
we always gave them an empty string. This is the right thing
to do, but in practice no callers probably use it (since now
we have an explicit separate "path" field, which was the
point of 2073949).

We add tests here not only for the broken case, but also a
basic sanity test of "log --source" in general, which did
not have any coverage in the test suite.

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

Merge branch 'fr/rebase-i-continue-preserve-options'

"git rebase -i" started with merge strategy options did not
propagate them upon "git rebase --continue".

* fr/rebase-i-continue-preserve-options:
  rebase -i: remember merge options beyond continue actions

Merge branch 'maint'

* maint:
  credential-store: don't pass strerror to die_errno()

push: add '-d' as shorthand for '--delete'

"git push" takes "--delete" but does not take a short form "-d",
unlike "git branch" which does take both.  Bring consistency
between them.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodules: allow parallel fetching, add tests and documentation

This enables the work of the previous patches.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch_populated_submodules: use new parallel job processing

In a later patch we enable parallel processing of submodules, this
only adds the possibility for it. So this change should not change
any user facing behavior.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>