We just introduced the command-line option
`--initial-branch=<branch-name>` to allow initializing a new repository
with a different initial branch than the hard-coded one.

To allow users to override the initial branch name more permanently
(i.e. without having to specify the name manually for each and every
`git init` invocation), let's introduce the `init.defaultBranch` config
setting.
Helped-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Helped-by: NDerrick Stolee <dstolee@microsoft.com>
Signed-off-by: NDon Goodman-Wilson <don@goodman-wilson.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There is a growing number of projects and companies desiring to change
the main branch name of their repositories (see e.g.
https://twitter.com/mislav/status/1270388510684598272 for background on
this).

To change that branch name for new repositories, currently the only way
to do that automatically is by copying all of Git's template directory,
then hard-coding the desired default branch name into the `.git/HEAD`
file, and then configuring `init.templateDir` to point to those copied
template files.

To make this process much less cumbersome, let's introduce a new option:
`--initial-branch=<branch-name>`.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There were a couple of instances in our manual pages that had an
opening diamond bracket without a corresponding closing one.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When `remote.<name>.branch` is not configured, `git submodule update`
currently falls back to using the branch name `master`. A much better
idea, however, is to use the remote `HEAD`: on all Git servers running
reasonably recent Git versions, the symref `HEAD` points to the main
branch.

Note: t7419 demonstrates that there _might_ be use cases out there that
_expect_ `git submodule update --remote` to update submodules to the
remote `master` branch even if the remote `HEAD` points to another
branch. Arguably, this patch makes the behavior more intuitive, but
there is a slight possibility that this might cause regressions in
obscure setups.

Even so, it should be okay to fix this behavior without anything like a
longer transition period:

- The `git submodule update --remote` command is not really common.

- Current Git's behavior when running this command is outright
  confusing, unless the remote repository's current branch _is_ `master`
  (in which case the proposed behavior matches the old behavior).

- If a user encounters a regression due to the changed behavior, the fix
  is actually trivial: setting `submodule.<name>.branch` to `master`
  will reinstate the old behavior.
Helped-by: NPhilippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When trying to push all matching branches, but none match, we offer a
message suggesting to push the `master` branch.

However, we want to step away from making that branch any more special
than any other branch, so let's reword that message to mention no branch
in particular.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In the context of many projects renaming their primary branch names away
from `master`, Git wants to stop treating the `master` branch specially.

Let's start with `git fmt-merge-msg`.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Rewrite support for GIT_CURL_VERBOSE in terms of GIT_TRACE_CURL.

Looking good.

* jt/curl-verbose-on-trace-curl:
  http, imap-send: stop using CURLOPT_VERBOSE
  t5551: test that GIT_TRACE_CURL redacts password

Code clean-up.

* cc/upload-pack-data:
  upload-pack: use upload_pack_data fields in receive_needs()
  upload-pack: pass upload_pack_data to create_pack_file()
  upload-pack: remove static variable 'stateless_rpc'
  upload-pack: pass upload_pack_data to check_non_tip()
  upload-pack: pass upload_pack_data to send_ref()
  upload-pack: move symref to upload_pack_data
  upload-pack: use upload_pack_data writer in receive_needs()
  upload-pack: pass upload_pack_data to receive_needs()
  upload-pack: pass upload_pack_data to get_common_commits()
  upload-pack: use 'struct upload_pack_data' in upload_pack()
  upload-pack: move 'struct upload_pack_data' around
  upload-pack: move {want,have}_obj to upload_pack_data
  upload-pack: remove unused 'wants' from upload_pack_data

The code to parse "git bisect start" command line was lax in
validating the arguments.

* cb/bisect-helper-parser-fix:
  bisect--helper: avoid segfault with bad syntax in `start --term-*`

"git checkout -p" did not handle a newly added path at all.

* js/checkout-p-new-file:
  checkout -p: handle new files correctly

On-the-wire protocol v2 easily falls into a deadlock between the
remote-curl helper and the fetch-pack process when the server side
prematurely throws an error and disconnects.  The communication has
been updated to make it more robust.

* dl/remote-curl-deadlock-fix:
  stateless-connect: send response end packet
  pkt-line: define PACKET_READ_RESPONSE_END
  remote-curl: error on incomplete packet
  pkt-line: extern packet_length()
  transport: extract common fetch_pack() call
  remote-curl: remove label indentation
  remote-curl: fix typo

Code simplification and test coverage enhancement.

* bc/filter-process:
  t2060: add a test for switch with --orphan and --discard-changes
  builtin/checkout: simplify metadata initialization

The command line completion script (in contrib/) tried to complete
"git stash -p" as if it were "git stash push -p", but it was too
aggressive and also affected "git stash show -p", which has been
corrected.

* vs/complete-stash-show-p-fix:
  completion: don't override given stash subcommand with -p

The check in "git fsck" to ensure that the tree objects are sorted
still had corner cases it missed unsorted entries.

* rs/fsck-duplicate-names-in-trees:
  fsck: detect more in-tree d/f conflicts
  t1450: demonstrate undetected in-tree d/f conflict
  t1450: increase test coverage of in-tree d/f detection
  fsck: fix a typo in a comment

"git bugreport" learns to report what shell is in use.

* es/bugreport-shell:
  bugreport: include user interactive shell
  help: add shell-path to --build-options

Clean-up the commit-graph codepath.

* tb/commit-graph-no-check-oids:
  commit-graph: drop COMMIT_GRAPH_WRITE_CHECK_OIDS flag
  t5318: reorder test below 'graph_read_expect'
  commit-graph.c: simplify 'fill_oids_from_commits'
  builtin/commit-graph.c: dereference tags in builtin
  builtin/commit-graph.c: extract 'read_one_commit()'
  commit-graph.c: peel refs in 'add_ref_to_set'
  commit-graph.c: show progress of finding reachable commits
  commit-graph.c: extract 'refs_cb_data'

As FreeBSD is not the only platform whose regexp library reports
a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that
automatically and skip the affected tests.

* cb/t4210-illseq-auto-detect:
  t4210: detect REG_ILLSEQ dynamically and skip affected tests
  t/helper: teach test-regex to report pattern errors (like REG_ILLSEQ)

"git log -L..." now takes advantage of the "which paths are touched
by this commit?" info stored in the commit-graph system.

* ds/line-log-on-bloom:
  line-log: integrate with changed-path Bloom filters
  line-log: try to use generation number-based topo-ordering
  line-log: more responsive, incremental 'git log -L'
  t4211-line-log: add tests for parent oids
  line-log: remove unused fields from 'struct line_log_data'

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

Some repositories in the wild have commits that record nonsense
committer timezone (e.g. rails.git); "git fast-import" learned an
option to pass these nonsense timestamps intact to allow recreating
existing repositories as-is.

* en/fast-import-looser-date:
  fast-import: add new --date-format=raw-permissive format

Command line completion (incontrib/) update.

* mt/zsh-completion-optim:
  completion: use native ZSH array pattern matching

The commands in the "diff" family learned to honor "diff.relative"
configuration variable.

* la/diff-relative-config:
  diff: add config option relative

The error message from "git checkout -b foo -t bar baz" was
confusing.

* rs/checkout-b-track-error:
  checkout: improve error messages for -b with extra argument
  checkout: add tests for -b and --track

We've adopted a convention that any on-stack structure can be
initialized to have zero values in all fields with "= { 0 }", even
when the first field happens to be a pointer, but sparse complained
that a null pointer should be spelled NULL for a long time.  Start
using -Wno-universal-initializer option to squelch it.

* lo/sparse-universal-zero-init:
  sparse: allow '{ 0 }' to be used without warnings

Test fixup.

* cb/t5608-cleanup:
  t5608: avoid say() and use "skip_all" instead for consistency

Docfix.

* jx/pkt-line-doc-count-fix:
  doc: fix wrong 4-byte length of pkt-line message

"feature.experimental" configuration variable is to let volunteers
easily opt into a set of newer features, which use of the v2
transport protocol is now a part of.

* jn/experimental-opts-into-proto-v2:
  config: let feature.experimental imply protocol.version=2

The "--prepare-p4-only" option is supposed to stop after replaying
one changeset, but kept going (by mistake?)

* bk/p4-prepare-p4-only-fix:
  git-p4.py: fix --prepare-p4-only error with multiple commits

Code optimization for a common case.

* an/merge-single-strategy-optim:
  merge: optimization to skip evaluate_result for single strategy

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

Portability fix for tests added recently.

* cb/test-use-ere-for-alternation:
  t: avoid alternation (not POSIX) in grep's BRE

l10n-2.27.0-rnd2

* tag 'l10n-2.27.0-rnd2' of git://github.com/git-l10n/git-po: (23 commits)
  l10n: zh_TW.po: v2.27.0 round 2 (0 untranslated)
  l10n: zh_TW.po: v2.27.0 round 1 (0 untranslated)
  l10n: de.po: Fix typo in the German translation of octopus
  l10n: de.po: Update German translation for Git 2.27.0
  l10n: it.po: update for Git 2.27.0 round #2
  l10n: tr: v2.27.0 round 2
  l10n: fr.po v2.27.0 rnd 2
  l10n: bg.po: Updated Bulgarian translation (4875t)
  l10n: Update Catalan translation
  l10n: sv.po: Update Swedish translation (4875t0f0u)
  l10n: vi(4875t): Updated Vietnamses translation for 2.27.0rd2
  l10n: zh_CN: for git v2.27.0 l10n round 1~2
  l10n: git.pot: v2.27.0 round 2 (+1)
  l10n: Update Catalan translation
  l10n: vi(4874t): Updated Vietnamses translation for 2.27.0
  l10n: es: 2.27.0 round 1
  l10n: bg.po: Updated Bulgarian translation (4868t)
  l10n: fr v2.27.0 rnd 1
  l10n: sv.po: Update Swedish translation (4839t0f0u)
  l10n: tr: v2.27.0 round 1
  ...

There are multiple repositories in the wild with random, invalid
timezones.  Most notably is a commit from rails.git with a timezone of
"+051800"[1].  A few searches will find other repos with that same
invalid timezone as well.  Further, Peff reports that GitHub relaxed
their fsck checks in August 2011 to accept any timezone value[2], and
there have been multiple reports to filter-repo about fast-import
crashing while trying to import their existing repositories since they
had timezone values such as "-7349423" and "-43455309"[3].

The existing check on timezone values inside fast-import may prove
useful for people who are crafting fast-import input by hand or with a
new script.  For them, the check may help them avoid accidentally
recording invalid dates.  (Note that this check is rather simplistic and
there are still several forms of invalid dates that fast-import does not
check for: dates in the future, timezone values with minutes that are
not divisible by 15, and timezone values with minutes that are 60 or
greater.)  While this simple check may have some value for those users,
other users or tools will want to import existing repositories as-is.
Provide a --date-format=raw-permissive format that will not error out on
these otherwise invalid timezones so that such existing repositories can
be imported.

[1] https://github.com/rails/rails/commit/4cf94979c9f4d6683c9338d694d5eb3106a4e734
[2] https://lore.kernel.org/git/20200521195513.GA1542632@coredump.intra.peff.net/
[3] https://github.com/newren/git-filter-repo/issues/88Signed-off-by: NElijah Newren <newren@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'master' of github.com:ruester/git-po-de:
  l10n: de.po: Fix typo in the German translation of octopus
  l10n: de.po: Update German translation for Git 2.27.0

* 'update-italian-translation' of github.com:AlessandroMenti/git-po:
  l10n: it.po: update for Git 2.27.0 round #2

Docfix.

* bc/sha-256-part-1-of-4:
  Documentation: correct hash environment variable

Docfix.

* ma/rev-list-options-docfix:
  rev-list-options.txt: start a list for `show-pulls`

Dev support.

* jk/ci-only-on-selected-branches:
  ci/config: correct instruction for CI preferences

f1e3df31 (t: increase test coverage of signature verification output,
2020-03-04) adds GPG dependent tests to t4202 and t6200 that were found
problematic with at least OpenBSD 6.7.

Using an escaped '|' for alternations works only in some implementations
of grep (e.g. GNU and busybox).

It is not part of POSIX[1] and not supported by some BSD, macOS, and
possibly other POSIX compatible implementations.

Use `grep -E`, and write it using extended regular expression.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03Helped-by: NTorsten Bögershausen <tboegi@web.de>
Signed-off-by: NCarlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>