git/git.git
3 years agotest-hashmap: use "unsigned int" for hash storage
Jeff King [Wed, 14 Feb 2018 18:08:57 +0000 (13:08 -0500)]
test-hashmap: use "unsigned int" for hash storage

The hashmap API always use an unsigned value for storing
and comparing hashes. Whereas this test code uses "int".
This works out in practice since one can typically
round-trip between "int" and "unsigned int". But since this
is essentially reference code for the hashmap API, we should
model using the correct types.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agotest-hashmap: simplify alloc_test_entry
Jeff King [Wed, 14 Feb 2018 18:08:20 +0000 (13:08 -0500)]
test-hashmap: simplify alloc_test_entry

This function takes two ptr/len pairs, which implies that
they can be arbitrary buffers. But internally, it assumes
that each "ptr" is NUL-terminated at "len" (because we
memcpy an extra byte to pick up the NUL terminator).

In practice this works because each caller only ever passes
strlen(ptr) as the length. But let's drop the "len"
parameters to make our expectations clear.

Note that we can get rid of the "l1" and "l2" variables from
cmd_main() as a further cleanup, since they are now mostly
used to check whether the p1 and p2 arguments are present
(technically the length parameters conflated NULL with the
empty string, which we no longer do, but I think that is
actually an improvement).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agotest-hashmap: use strbuf_getline rather than fgets
Jeff King [Wed, 14 Feb 2018 18:07:19 +0000 (13:07 -0500)]
test-hashmap: use strbuf_getline rather than fgets

Using fgets() with a fixed-size buffer can lead to lines
being accidentally split across two calls if they are larger
than the buffer size.

As this is just a test helper, this is unlikely to be a
problem in practice. But since people may look at test
helpers as reference code, it's a good idea for them to
model the preferred behavior.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agotest-hashmap: use xsnprintf rather than snprintf
Jeff King [Wed, 14 Feb 2018 18:06:57 +0000 (13:06 -0500)]
test-hashmap: use xsnprintf rather than snprintf

In general, using a bare snprintf can truncate the resulting
buffer, leading to confusing results. In this case we know
that our buffer is sized large enough to accommodate our
loop, so there's no bug. However, we should use xsnprintf()
to document (and check) that assumption, and to model good
practice to people reading the code.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agotest-hashmap: check allocation computation for overflow
Jeff King [Wed, 14 Feb 2018 18:06:34 +0000 (13:06 -0500)]
test-hashmap: check allocation computation for overflow

When we allocate the test_entry flex-struct, we have to add
up all of the elements that go into the flex array. If these
were to overflow a size_t, this would allocate a too-small
buffer, which we would then overflow in our memcpy steps.

Since this is just a test-helper, it probably doesn't matter
in practice, but we should model the correct technique by
using the st_add() macros.

Unfortunately, we cannot use the FLEX_ALLOC() macros here,
because we are stuffing two different buffers into a single
flex array.

While we're here, let's also swap out "malloc" for our
error-checking "xmalloc", and use the preferred
"sizeof(*var)" instead of "sizeof(type)".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agotest-hashmap: use ALLOC_ARRAY rather than bare malloc
Jeff King [Wed, 14 Feb 2018 18:05:46 +0000 (13:05 -0500)]
test-hashmap: use ALLOC_ARRAY rather than bare malloc

These two array allocations have several minor flaws:

  - they use bare malloc, rather than our error-checking
    xmalloc

  - they do a bare multiplication to determine the total
    size (which in theory can overflow, though in this case
    the sizes are all constants)

  - they use sizeof(type), but the type in the second one
    doesn't match the actual array (though it's "int" versus
    "unsigned int", which are guaranteed by C99 to have the
    same size)

None of these are likely to be problems in practice, and
this is just a test helper. But since people often look at
test helpers as reference code, we should do our best to
model the recommended techniques.

Switching to ALLOC_ARRAY fixes all three.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofsmonitor: update documentation to remove reference to invalid config settings
Ben Peart [Wed, 14 Feb 2018 15:41:30 +0000 (10:41 -0500)]
fsmonitor: update documentation to remove reference to invalid config settings

Remove the reference to setting core.fsmonitor to `true` (or `false`) as those
are not valid settings.

Signed-off-by: Ben Peart <benpeart@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoSecond batch for 2.17
Junio C Hamano [Wed, 14 Feb 2018 00:22:16 +0000 (16:22 -0800)]
Second batch for 2.17

Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoMerge branch 'tz/doc-show-defaults-to-head'
Junio C Hamano [Tue, 13 Feb 2018 21:39:17 +0000 (13:39 -0800)]
Merge branch 'tz/doc-show-defaults-to-head'

Doc update.

* tz/doc-show-defaults-to-head:
  doc: mention 'git show' defaults to HEAD

3 years agoMerge branch 'ew/svn-branch-segfault-fix'
Junio C Hamano [Tue, 13 Feb 2018 21:39:16 +0000 (13:39 -0800)]
Merge branch 'ew/svn-branch-segfault-fix'

Workaround for segfault with more recent versions of SVN.

* ew/svn-branch-segfault-fix:
  git-svn: control destruction order to avoid segfault

3 years agoMerge branch 'sg/travis-linux32-sanity'
Junio C Hamano [Tue, 13 Feb 2018 21:39:16 +0000 (13:39 -0800)]
Merge branch 'sg/travis-linux32-sanity'

Travis updates.

* sg/travis-linux32-sanity:
  travis-ci: don't fail if user already exists on 32 bit Linux build job
  travis-ci: don't run the test suite as root in the 32 bit Linux build
  travis-ci: don't repeat the path of the cache directory
  travis-ci: use 'set -e' in the 32 bit Linux build job
  travis-ci: use 'set -x' for the commands under 'su' in the 32 bit Linux build

3 years agoMerge branch 'nd/list-merge-strategy'
Junio C Hamano [Tue, 13 Feb 2018 21:39:15 +0000 (13:39 -0800)]
Merge branch 'nd/list-merge-strategy'

Completion of "git merge -s<strategy>" (in contrib/) did not work
well in non-C locale.

* nd/list-merge-strategy:
  completion: fix completing merge strategies on non-C locales

3 years agoMerge branch 'jt/long-running-process-doc'
Junio C Hamano [Tue, 13 Feb 2018 21:39:15 +0000 (13:39 -0800)]
Merge branch 'jt/long-running-process-doc'

Doc updates.

* jt/long-running-process-doc:
  Docs: split out long-running subprocess handshake

3 years agoMerge branch 'jk/daemon-fixes'
Junio C Hamano [Tue, 13 Feb 2018 21:39:15 +0000 (13:39 -0800)]
Merge branch 'jk/daemon-fixes'

Assorted fixes to "git daemon".

* jk/daemon-fixes:
  daemon: fix length computation in newline stripping
  t/lib-git-daemon: add network-protocol helpers
  daemon: handle NULs in extended attribute string
  daemon: fix off-by-one in logging extended attributes
  t/lib-git-daemon: record daemon log
  t5570: use ls-remote instead of clone for interp tests

3 years agoMerge branch 'pw/sequencer-in-process-commit'
Junio C Hamano [Tue, 13 Feb 2018 21:39:15 +0000 (13:39 -0800)]
Merge branch 'pw/sequencer-in-process-commit'

The sequencer infrastructure is shared across "git cherry-pick",
"git rebase -i", etc., and has always spawned "git commit" when it
needs to create a commit.  It has been taught to do so internally,
when able, by reusing the codepath "git commit" itself uses, which
gives performance boost for a few tens of percents in some sample
scenarios.

* pw/sequencer-in-process-commit:
  sequencer: run 'prepare-commit-msg' hook
  t7505: add tests for cherry-pick and rebase -i/-p
  t7505: style fixes
  sequencer: assign only free()able strings to gpg_sign
  sequencer: improve config handling
  t3512/t3513: remove KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1
  sequencer: try to commit without forking 'git commit'
  sequencer: load commit related config
  sequencer: simplify adding Signed-off-by: trailer
  commit: move print_commit_summary() to libgit
  commit: move post-rewrite code to libgit
  Add a function to update HEAD after creating a commit
  commit: move empty message checks to libgit
  t3404: check intermediate squash messages

3 years agoMerge branch 'nd/shared-index-fix'
Junio C Hamano [Tue, 13 Feb 2018 21:39:14 +0000 (13:39 -0800)]
Merge branch 'nd/shared-index-fix'

Code clean-up.

* nd/shared-index-fix:
  read-cache: don't write index twice if we can't write shared index
  read-cache.c: move tempfile creation/cleanup out of write_shared_index
  read-cache.c: change type of "temp" in write_shared_index()

3 years agoMerge branch 'po/http-push-error-message'
Junio C Hamano [Tue, 13 Feb 2018 21:39:14 +0000 (13:39 -0800)]
Merge branch 'po/http-push-error-message'

Debugging aid.

* po/http-push-error-message:
  http-push: improve error log

3 years agoMerge branch 'po/clang-format-functype-weight'
Junio C Hamano [Tue, 13 Feb 2018 21:39:14 +0000 (13:39 -0800)]
Merge branch 'po/clang-format-functype-weight'

Prevent "clang-format" from breaking line after function return type.

* po/clang-format-functype-weight:
  clang-format: adjust penalty for return type line break

3 years agoMerge branch 'jc/mailinfo-cleanup-fix'
Junio C Hamano [Tue, 13 Feb 2018 21:39:14 +0000 (13:39 -0800)]
Merge branch 'jc/mailinfo-cleanup-fix'

Corner case bugfix.

* jc/mailinfo-cleanup-fix:
  mailinfo: avoid segfault when can't open files

3 years agoMerge branch 'sg/cocci-move-array'
Junio C Hamano [Tue, 13 Feb 2018 21:39:13 +0000 (13:39 -0800)]
Merge branch 'sg/cocci-move-array'

Code clean-up.

* sg/cocci-move-array:
  Use MOVE_ARRAY

3 years agoMerge branch 'tg/split-index-fixes'
Junio C Hamano [Tue, 13 Feb 2018 21:39:12 +0000 (13:39 -0800)]
Merge branch 'tg/split-index-fixes'

The split-index mode had a few corner case bugs fixed.

* tg/split-index-fixes:
  travis: run tests with GIT_TEST_SPLIT_INDEX
  split-index: don't write cache tree with null oid entries
  read-cache: fix reading the shared index for other repos

3 years agoMerge branch 'rs/strbuf-cocci-workaround'
Junio C Hamano [Tue, 13 Feb 2018 21:39:12 +0000 (13:39 -0800)]
Merge branch 'rs/strbuf-cocci-workaround'

Update Coccinelle rules to catch and optimize strbuf_addf(&buf, "%s", str)

* rs/strbuf-cocci-workaround:
  cocci: use format keyword instead of a literal string

3 years agoMerge branch 'mr/packed-ref-store-fix'
Junio C Hamano [Tue, 13 Feb 2018 21:39:11 +0000 (13:39 -0800)]
Merge branch 'mr/packed-ref-store-fix'

Crash fix for a corner case where an error codepath tried to unlock
what it did not acquire lock on.

* mr/packed-ref-store-fix:
  files_initial_transaction_commit(): only unlock if locked

3 years agoMerge branch 'jt/http-redact-cookies'
Junio C Hamano [Tue, 13 Feb 2018 21:39:11 +0000 (13:39 -0800)]
Merge branch 'jt/http-redact-cookies'

The http tracing code, often used to debug connection issues,
learned to redact potentially sensitive information from its output
so that it can be more safely sharable.

* jt/http-redact-cookies:
  http: support omitting data from traces
  http: support cookie redaction when tracing

3 years agoMerge branch 'ds/use-get-be64'
Junio C Hamano [Tue, 13 Feb 2018 21:39:11 +0000 (13:39 -0800)]
Merge branch 'ds/use-get-be64'

Code clean-up.

* ds/use-get-be64:
  packfile: use get_be64() for large offsets

3 years agoMerge branch 'cc/sha1-file-name'
Junio C Hamano [Tue, 13 Feb 2018 21:39:10 +0000 (13:39 -0800)]
Merge branch 'cc/sha1-file-name'

Code clean-up.

* cc/sha1-file-name:
  sha1_file: improve sha1_file_name() perfs
  sha1_file: remove static strbuf from sha1_file_name()

3 years agoMerge branch 'nd/trace-with-env'
Junio C Hamano [Tue, 13 Feb 2018 21:39:10 +0000 (13:39 -0800)]
Merge branch 'nd/trace-with-env'

The tracing machinery learned to report tweaking of environment
variables as well.

* nd/trace-with-env:
  run-command.c: print new cwd in trace_run_command()
  run-command.c: print env vars in trace_run_command()
  run-command.c: print program 'git' when tracing git_cmd mode
  run-command.c: introduce trace_run_command()
  trace.c: move strbuf_release() out of print_trace_line()
  trace: avoid unnecessary quoting
  sq_quote_argv: drop maxlen parameter

3 years agoMerge branch 'pc/submodule-helper'
Junio C Hamano [Tue, 13 Feb 2018 21:39:10 +0000 (13:39 -0800)]
Merge branch 'pc/submodule-helper'

Rewrite two more "git submodule" subcommands in C.

* pc/submodule-helper:
  submodule: port submodule subcommand 'deinit' from shell to C
  submodule: port submodule subcommand 'sync' from shell to C

3 years agoMerge branch 'rb/hashmap-h-compilation-fix'
Junio C Hamano [Tue, 13 Feb 2018 21:39:10 +0000 (13:39 -0800)]
Merge branch 'rb/hashmap-h-compilation-fix'

Code clean-up.

* rb/hashmap-h-compilation-fix:
  hashmap.h: remove unused variable

3 years agoMerge branch 'nd/diff-flush-before-warning'
Junio C Hamano [Tue, 13 Feb 2018 21:39:09 +0000 (13:39 -0800)]
Merge branch 'nd/diff-flush-before-warning'

Avoid showing a warning message in the middle of a line of "git
diff" output.

* nd/diff-flush-before-warning:
  diff.c: flush stdout before printing rename warnings

3 years agoMerge branch 'tb/crlf-conv-flags'
Junio C Hamano [Tue, 13 Feb 2018 21:39:08 +0000 (13:39 -0800)]
Merge branch 'tb/crlf-conv-flags'

Code clean-up.

* tb/crlf-conv-flags:
  convert_to_git(): safe_crlf/checksafe becomes int conv_flags

3 years agoMerge branch 'rs/describe-unique-abbrev'
Junio C Hamano [Tue, 13 Feb 2018 21:39:07 +0000 (13:39 -0800)]
Merge branch 'rs/describe-unique-abbrev'

Code clean-up.

* rs/describe-unique-abbrev:
  describe: use strbuf_add_unique_abbrev() for adding short hashes

3 years agoMerge branch 'ks/submodule-doc-updates'
Junio C Hamano [Tue, 13 Feb 2018 21:39:07 +0000 (13:39 -0800)]
Merge branch 'ks/submodule-doc-updates'

Doc updates.

* ks/submodule-doc-updates:
  Doc/git-submodule: improve readability and grammar of a sentence
  Doc/gitsubmodules: make some changes to improve readability and syntax

3 years agoMerge branch 'cl/t9001-cleanup'
Junio C Hamano [Tue, 13 Feb 2018 21:39:07 +0000 (13:39 -0800)]
Merge branch 'cl/t9001-cleanup'

Test clean-up.

* cl/t9001-cleanup:
  t9001: use existing helper in send-email test

3 years agoMerge branch 'gs/retire-mru'
Junio C Hamano [Tue, 13 Feb 2018 21:39:06 +0000 (13:39 -0800)]
Merge branch 'gs/retire-mru'

Retire mru API as it does not give enough abstraction over
underlying list API to be worth it.

* gs/retire-mru:
  mru: Replace mru.[ch] with list.h implementation

3 years agoMerge branch 'ot/mru-on-list'
Junio C Hamano [Tue, 13 Feb 2018 21:39:05 +0000 (13:39 -0800)]
Merge branch 'ot/mru-on-list'

The first step to getting rid of mru API and using the
doubly-linked list API directly instead.

* ot/mru-on-list:
  mru: use double-linked list from list.h

3 years agoMerge branch 'jh/partial-clone'
Junio C Hamano [Tue, 13 Feb 2018 21:39:04 +0000 (13:39 -0800)]
Merge branch 'jh/partial-clone'

The machinery to clone & fetch, which in turn involves packing and
unpacking objects, have been told how to omit certain objects using
the filtering mechanism introduced by the jh/object-filtering
topic, and also mark the resulting pack as a promisor pack to
tolerate missing objects, taking advantage of the mechanism
introduced by the jh/fsck-promisors topic.

* jh/partial-clone:
  t5616: test bulk prefetch after partial fetch
  fetch: inherit filter-spec from partial clone
  t5616: end-to-end tests for partial clone
  fetch-pack: restore save_commit_buffer after use
  unpack-trees: batch fetching of missing blobs
  clone: partial clone
  partial-clone: define partial clone settings in config
  fetch: support filters
  fetch: refactor calculation of remote list
  fetch-pack: test support excluding large blobs
  fetch-pack: add --no-filter
  fetch-pack, index-pack, transport: partial clone
  upload-pack: add object filtering for partial clone

3 years agoMerge branch 'jh/fsck-promisors'
Junio C Hamano [Tue, 13 Feb 2018 21:39:03 +0000 (13:39 -0800)]
Merge branch 'jh/fsck-promisors'

In preparation for implementing narrow/partial clone, the machinery
for checking object connectivity used by gc and fsck has been
taught that a missing object is OK when it is referenced by a
packfile specially marked as coming from trusted repository that
promises to make them available on-demand and lazily.

* jh/fsck-promisors:
  gc: do not repack promisor packfiles
  rev-list: support termination at promisor objects
  sha1_file: support lazily fetching missing objects
  introduce fetch-object: fetch one promisor object
  index-pack: refactor writing of .keep files
  fsck: support promisor objects as CLI argument
  fsck: support referenced promisor objects
  fsck: support refs pointing to promisor objects
  fsck: introduce partialclone extension
  extension.partialclone: introduce partial clone extension

3 years agoMerge branch 'ab/simplify-perl-makefile'
Junio C Hamano [Tue, 13 Feb 2018 21:39:03 +0000 (13:39 -0800)]
Merge branch 'ab/simplify-perl-makefile'

The build procedure for perl/ part has been greatly simplified by
weaning ourselves off of MakeMaker.

* ab/simplify-perl-makefile:
  perl: treat PERLLIB_EXTRA as an extra path again
  perl: avoid *.pmc and fix Error.pm further
  Makefile: replace perl/Makefile.PL with simple make rules

3 years agoadd -p: improve error messages
Phillip Wood [Tue, 13 Feb 2018 10:32:41 +0000 (10:32 +0000)]
add -p: improve error messages

If the user presses a key that isn't currently active then explain why
it isn't active rather than just listing all the keys. It already did
this for some keys, this patch does the same for the those that
weren't already handled.

Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoadd -p: only bind search key if there's more than one hunk
Phillip Wood [Tue, 13 Feb 2018 10:32:40 +0000 (10:32 +0000)]
add -p: only bind search key if there's more than one hunk

If there is only a single hunk then disable searching as there is
nothing to search for. Also print a specific error message if the user
tries to search with '/' when there's only a single hunk rather than
just listing the key bindings.

Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoadd -p: only display help for active keys
Phillip Wood [Tue, 13 Feb 2018 10:32:39 +0000 (10:32 +0000)]
add -p: only display help for active keys

If the user presses a key that add -p wasn't expecting then it prints
a list of key bindings. Although the prompt only lists the active
bindings the help was printed for all bindings.  Fix this by using the
list of keys in the prompt to filter the help. Note that the list of
keys was already passed to help_patch_cmd() by the caller so there is
no change needed to the call site.

Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoMark messages for translations
Alexander Shopov [Tue, 13 Feb 2018 13:19:15 +0000 (14:19 +0100)]
Mark messages for translations

Small changes in messages to fit the style and typography of rest.
Reuse already translated messages if possible.
Do not translate messages aimed at developers of git.
Fix unit tests depending on the original string.
Use `test_i18ngrep` for tests with translatable strings.
Change and verify rest of tests via `make GETTEXT_POISON=1 test`.

Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot6300-for-each-ref: fix "more than one quoting style" tests
SZEDER Gábor [Tue, 13 Feb 2018 00:36:01 +0000 (01:36 +0100)]
t6300-for-each-ref: fix "more than one quoting style" tests

'git for-each-ref' should error out when invoked with more than one
quoting style options.  The tests checking this have two issues:

  - They run 'git for-each-ref' upstream of a pipe, hiding its exit
    code, thus don't actually checking that 'git for-each-ref' exits
    with error code.

  - They check the error message in a rather roundabout way.

Ensure that 'git for-each-ref' exits with an error code using the
'test_must_fail' helper function, and check its error message by
grepping its saved standard error.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agocolor.h: document and modernize header
Stefan Beller [Tue, 13 Feb 2018 01:41:30 +0000 (17:41 -0800)]
color.h: document and modernize header

Add documentation explaining the functions in color.h.
While at it, migrate the function `color_set` into grep.c,
where the only callers are.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agodocs/interpret-trailers: fix agreement error
brian m. carlson [Tue, 13 Feb 2018 02:23:52 +0000 (02:23 +0000)]
docs/interpret-trailers: fix agreement error

In the description of git interpret-trailers, we describe "a group…of
lines" that have certain characteristics.  Ensure both options
describing this group use a singular verb for parallelism.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agorebase: introduce and use pseudo-ref REBASE_HEAD
Nguyễn Thái Ngọc Duy [Sun, 11 Feb 2018 09:43:28 +0000 (16:43 +0700)]
rebase: introduce and use pseudo-ref REBASE_HEAD

The new command `git rebase --show-current-patch` is useful for seeing
the commit related to the current rebase state. Some however may find
the "git show" command behind it too limiting. You may want to
increase context lines, do a diff that ignores whitespaces...

For these advanced use cases, the user can execute any command they
want with the new pseudo ref REBASE_HEAD.

This also helps show where the stopped commit is from, which is hard
to see from the previous patch which implements --show-current-patch.

Helped-by: Tim Landscheidt <tim@tim-landscheidt.de>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agorebase: add --show-current-patch
Nguyễn Thái Ngọc Duy [Sun, 11 Feb 2018 09:43:27 +0000 (16:43 +0700)]
rebase: add --show-current-patch

It is useful to see the full patch while resolving conflicts in a
rebase. The only way to do it now is

    less .git/rebase-*/patch

which could turn out to be a lot longer to type if you are in a
linked worktree, or not at top-dir. On top of that, an ordinary user
should not need to peek into .git directory. The new option is
provided to examine the patch.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoam: add --show-current-patch
Nguyễn Thái Ngọc Duy [Sun, 11 Feb 2018 09:43:26 +0000 (16:43 +0700)]
am: add --show-current-patch

Pointing the user to $GIT_DIR/rebase-apply may encourage them to mess
around in there, which is not a good thing. With this, the user does
not have to keep the path around somewhere (because after a couple of
commands, the path may be out of scrollback buffer) when they need to
look at the patch.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agocheck-ignore: fix mix of directories and other file types
René Scharfe [Sat, 10 Feb 2018 12:38:29 +0000 (13:38 +0100)]
check-ignore: fix mix of directories and other file types

In check_ignore(), the first pathspec item determines the dtype for any
subsequent ones.  That means that a pathspec matching a regular file can
prevent following pathspecs from matching directories, which makes no
sense.  Fix that by determining the dtype for each pathspec separately,
by passing the value DT_UNKNOWN to last_exclude_matching() each time.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agosend-email: error out when relogin delay is missing
Stefan Beller [Mon, 12 Feb 2018 19:44:04 +0000 (11:44 -0800)]
send-email: error out when relogin delay is missing

When the batch size is neither configured nor given on the command
line, but the relogin delay is given, then the current code ignores
the relogin delay setting.

This is unsafe as there was some intention when setting the batch size.
One workaround would be to just assume a batch size of 1 as a default.
This however may be bad UX, as then the user may wonder why it is sending
slowly without apparent batching.

Error out for now instead of potentially confusing the user.
As 5453b83bdf (send-email: --batch-size to work around some SMTP
server limit, 2017-05-21) lays out, we rather want to not have this
interface anyway and would rather want to react on the server throttling
dynamically.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agodescribe: confirm that blobs actually exist
Jeff King [Mon, 12 Feb 2018 17:23:06 +0000 (12:23 -0500)]
describe: confirm that blobs actually exist

Prior to 644eb60bd0 (builtin/describe.c: describe a blob,
2017-11-15), we noticed and complained about missing
objects, since they were not valid commits:

  $ git describe 0000000000000000000000000000000000000000
  fatal: 0000000000000000000000000000000000000000 is not a valid 'commit' object

After that commit, we feed any non-commit to lookup_blob(),
and complain only if it returns NULL. But the lookup_*
functions do not actually look at the on-disk object
database at all. They return an entry from the in-memory
object hash if present (and if it matches the requested
type), and otherwise auto-create a "struct object" of the
requested type.

A missing object would hit that latter case: we create a
bogus blob struct, walk all of history looking for it, and
then exit successfully having produced no output.

One reason nobody may have noticed this is that some related
cases do still work OK:

  1. If we ask for a tree by sha1, then the call to
     lookup_commit_referecne_gently() would have parsed it,
     and we would have its true type in the in-memory object
     hash.

  2. If we ask for a name that doesn't exist but isn't a
     40-hex sha1, then get_oid() would complain before we
     even look at the objects at all.

We can fix this by replacing the lookup_blob() call with a
check of the true type via sha1_object_info(). This is not
quite as efficient as we could possibly make this check. We
know in most cases that the object was already parsed in the
earlier commit lookup, so we could call lookup_object(),
which does auto-create, and check the resulting struct's
type (or NULL).  However it's not worth the fragility nor
code complexity to save a single object lookup.

The new tests cover this case, as well as that of a
tree-by-sha1 (which does work as described above, but was
not explicitly tested).

Noticed-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoMakefile: suppress a sparse warning for pack-revindex.c
Ramsay Jones [Mon, 12 Feb 2018 00:21:02 +0000 (00:21 +0000)]
Makefile: suppress a sparse warning for pack-revindex.c

Sparse has, for a long time, been issuing the following warning against
the pack-revindex.c file:

      SP pack-revindex.c
  pack-revindex.c:64:23: warning: memset with byte count of 262144

This results from a unconditional check, with a hard-coded limit, which
is really only appropriate for the kernel source code. (The check is for
a 'large' byte count in a call to memcpy(), memset(), copy_from_user()
and copy_to_user() functions).

A recent release of sparse (v0.5.1) has introduced some options to allow
this check to be turned off (-Wno-memcpy-max-count) or to specify the
actual limit used (-fmemcpy-max-count=COUNT), rather than a hard-coded
limit of 100000.

In order to suppress the warning, add a target for pack-revindex.sp that
adds the '-Wno-memcpy-max-count' option to the SPARSE_FLAGS variable.

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoconfig.mak.uname: remove SPARSE_FLAGS setting for cygwin
Ramsay Jones [Mon, 12 Feb 2018 00:20:08 +0000 (00:20 +0000)]
config.mak.uname: remove SPARSE_FLAGS setting for cygwin

Since commit f66450ae9 ("cygwin: Remove the Win32 l/stat() implementation",
2013-06-22), the cygwin build has not used the WIN32 API/header files.
This means that the '-isystem /usr/include/w32api' option to sparse is
no longer necessary (to allow sparse to find the WIN32 header files).
In addition, the '-Wno-one-bit-signed-bitfield' option can be removed,
since the warning suppressed by that option was only provoked by a WIN32
header file.

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot0002: simplify error checking
Jeff King [Sat, 10 Feb 2018 11:31:29 +0000 (06:31 -0500)]
t0002: simplify error checking

This ancient test script does a lot of manual checking of
test conditions with "if" blocks. We can simplify this
by relying on helpers like test_must_fail.

Note that a failing "grep" call here won't produce any
verbose output, but that's OK. These days we rely on "-x" to
tell us about such commands. And in addition, these greps
are soon to be converted to test_i18ngrep (which is itself
soon learning to be more verbose).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot: document 'test_must_fail ok=<signal-name>'
SZEDER Gábor [Fri, 9 Feb 2018 02:42:33 +0000 (03:42 +0100)]
t: document 'test_must_fail ok=<signal-name>'

Since 'test_might_fail' is implemented as a thin wrapper around
'test_must_fail', it also accepts the same options.  Mention this in
the docs as well.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoupdate-index doc: note the caveat with "could not open..."
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 21:04:31 +0000 (21:04 +0000)]
update-index doc: note the caveat with "could not open..."

Note the caveat where 2.17 is stricter about index validation
potentially causing "could not open directory" warnings when git is
upgraded. See the preceding "dir.c: stop ignoring opendir() error in
open_cached_dir()" change.

This caused some mayhem when I upgraded git to a version with this
series at Booking.com, and other users have doubtless enabled the UC
extension and are in for a surprise when they upgrade. Let's give them
a headsup in the docs.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoupdate-index doc: note a fixed bug in the untracked cache
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 21:04:30 +0000 (21:04 +0000)]
update-index doc: note a fixed bug in the untracked cache

Document the bug tested for in my "status: add a failing test showing
a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
invalidation in untracked code".

Since this is very likely something others will encounter in the
future on older versions, and it's not obvious how to fix it let's
document both that it exists, and how to "fix" it with a one-off
command.

As noted in that commit, even though this bug gets the untracked cache
into a bad state, we have not yet found a case where this is user
visible, and thus it makes sense for these docs to focus on the
symlink case only.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch: make the --prune-tags work with <url>
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:16 +0000 (20:32 +0000)]
fetch: make the --prune-tags work with <url>

Make the new --prune-tags option work properly when git-fetch is
invoked with a <url> parameter instead of a <remote name>
parameter.

This change is split off from the introduction of --prune-tags due to
the relative complexity of munging the incoming argv, which is easier
to review as a separate change.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch: add a --prune-tags option and fetch.pruneTags config
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:15 +0000 (20:32 +0000)]
fetch: add a --prune-tags option and fetch.pruneTags config

Add a --prune-tags option to git-fetch, along with fetch.pruneTags
config option and a -P shorthand (-p is --prune). This allows for
doing any of:

    git fetch -p -P
    git fetch --prune --prune-tags
    git fetch -p -P origin
    git fetch --prune --prune-tags origin

Or simply:

    git config fetch.prune true &&
    git config fetch.pruneTags true &&
    git fetch

Instead of the much more verbose:

    git fetch --prune origin 'refs/tags/*:refs/tags/*' '+refs/heads/*:refs/remotes/origin/*'

Before this feature it was painful to support the use-case of pulling
from a repo which is having both its branches *and* tags deleted
regularly, and have our local references to reflect upstream.

At work we create deployment tags in the repo for each rollout, and
there's *lots* of those, so they're archived within weeks for
performance reasons.

Without this change it's hard to centrally configure such repos in
/etc/gitconfig (on servers that are only used for working with
them). You need to set fetch.prune=true globally, and then for each
repo:

    git -C {} config --replace-all remote.origin.fetch "refs/tags/*:refs/tags/*" "^\+*refs/tags/\*:refs/tags/\*$"

Now I can simply set fetch.pruneTags=true in /etc/gitconfig as well,
and users running "git pull" will automatically get the pruning
semantics I want.

Even though "git remote" has corresponding "prune" and "update
--prune" subcommands I'm intentionally not adding a corresponding
prune-tags or "update --prune --prune-tags" mode to that command.

It's advertised (as noted in my recent "git remote doc: correct
dangerous lies about what prune does") as only modifying remote
tracking references, whereas any --prune-tags option is always going
to modify what from the user's perspective is a local copy of the tag,
since there's no such thing as a remote tracking tag.

Ideally add_prune_tags_to_fetch_refspec() would be something that
would use ALLOC_GROW() to grow the 'fetch` member of the 'remote'
struct. Instead I'm realloc-ing remote->fetch and adding the
tag_refspec to the end.

The reason is that parse_{fetch,push}_refspec which allocate the
refspec (ultimately remote->fetch) struct are called many places that
don't have access to a 'remote' struct. It would be hard to change all
their callsites to be amenable to carry around the bookkeeping
variables required for dynamic allocation.

All the other callers of the API first incrementally construct the
string version of the refspec in remote->fetch_refspec via
add_fetch_refspec(), before finally calling parse_fetch_refspec() via
some variation of remote_get().

It's less of a pain to deal with the one special case that needs to
modify already constructed refspecs than to chase down and change all
the other callsites. The API I'm adding is intentionally not
generalized because if we add more of these we'd probably want to
re-visit how this is done.

See my "Re: [BUG] git remote prune removes local tags, depending on
fetch config" (87po6ahx87.fsf@evledraar.gmail.com;
https://public-inbox.org/git/87po6ahx87.fsf@evledraar.gmail.com/) for
more background info.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch tests: add scaffolding for the new fetch.pruneTags
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:14 +0000 (20:32 +0000)]
fetch tests: add scaffolding for the new fetch.pruneTags

The fetch.pruneTags configuration doesn't exist yet, but will be added
in a subsequent commit. Since testing for it requires adding new
parameters to the test_configured_prune function it's easier to review
this patch first to assert that no functional changes are introduced
yet.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agogit-fetch & config doc: link to the new PRUNING section
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:13 +0000 (20:32 +0000)]
git-fetch & config doc: link to the new PRUNING section

Amend the documentation for fetch.prune, fetch.<name>.prune and
--prune to link to the recently added PRUNING section.

I'd have liked to link directly to it with "<<PRUNING>>" from
fetch-options.txt, since it's included in git-fetch.txt (git-pull.txt
also includes it, but doesn't include that option). However making a
reference across files yields this error:

    [...]/Documentation/git-fetch.xml:226: element xref: validity
    error : IDREF attribute linkend references an unknown ID "PRUNING"

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agogit remote doc: correct dangerous lies about what prune does
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:12 +0000 (20:32 +0000)]
git remote doc: correct dangerous lies about what prune does

The "git remote prune <name>" command uses the same machinery as "git
fetch <name> --prune", and shares all the same caveats, but its
documentation has suggested that it'll just "delete stale
remote-tracking branches under <name>".

This isn't true, and hasn't been true since at least v1.8.5.6 (the
oldest version I could be bothered to test).

E.g. if "refs/tags/*:refs/tags/*" is explicitly set in the refspec of
the remote, it'll delete all local tags <name> doesn't know about.

Instead, briefly give the reader just enough of a hint that this
option might constitute a shotgun aimed at their foot, and point them
to the new PRUNING section in the git-fetch documentation which
explains all the nuances of what this facility does.

See "[BUG] git remote prune removes local tags, depending on fetch
config" (CACi5S_39wNrbfjLfn0xhCY+uewtFN2YmnAcRc86z6pjUTjWPHQ@mail.gmail.com)
by Michael Giuffrida for the initial report.

Reported-by: Michael Giuffrida <michaelpg@chromium.org>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agogit fetch doc: add a new section to explain the ins & outs of pruning
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:11 +0000 (20:32 +0000)]
git fetch doc: add a new section to explain the ins & outs of pruning

Add a new section to canonically explain how remote reference pruning
works, and how users should be careful about using it in conjunction
with tag refspecs in particular.

A subsequent commit will update the git-remote documentation to refer
to this section, and details the motivation for writing this in the
first place.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch tests: fetch <url> <spec> as well as fetch [<remote>]
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:10 +0000 (20:32 +0000)]
fetch tests: fetch <url> <spec> as well as fetch [<remote>]

When a remote URL is supplied on the command-line the internals of the
fetch are different, in particular the code in get_ref_map(). An
earlier version of the subsequent fetch.pruneTags patch hid a segfault
because the difference wasn't tested for.

Now all the tests are run as both of the variants of:

    git fetch
    git -c [...] fetch $(git config remote.origin.url) $(git config remote.origin.fetch)

I'm using -c because while the [fetch] config just set by
set_config_tristate will be picked up, the remote.origin.* config
won't override it as intended.

Work around that and turn this into a purely command-line test by
always setting the variables on the command-line, and translate any
setting of remote.origin.X into fetch.X.

The reason for choosing the names "name" and "link" as opposed to
e.g. "named" and "url" is because they're the same length, which makes
the test output easier to read as it will be aligned.

Due to shellscript quoting madness it's not worthwhile to do all of
this within a test_expect_success, but do the parts that can easily be
done there, including the one-time setting of variables that don't
change between runs to be used by subsequent runs in the 'prune_type
setup' test.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch tests: expand case/esac for later change
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:09 +0000 (20:32 +0000)]
fetch tests: expand case/esac for later change

Expand a compact case/esac statement for a later change that'll add
more logic to the body of the "*" case. This is a whitespace-only
change.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch tests: double quote a variable for interpolation
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:08 +0000 (20:32 +0000)]
fetch tests: double quote a variable for interpolation

If the $cmdline variable contains arguments with spaces they won't be
interpolated correctly, since the body of the test is single quoted,
and because test-lib.sh does its own eval().

This will be used in a subsequent commit to pass arguments that need
to be quoted to git-fetch, i.e. a file:// path to fetch, which will
have a space in it.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch tests: test --prune and refspec interaction
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:07 +0000 (20:32 +0000)]
fetch tests: test --prune and refspec interaction

Add a test for the interaction between explicitly provided refspecs
and fetch.prune.

There's no point in adding this boilerplate to every combination of
unset/false/true, it's instructive and sufficient to show that no
matter if the variable is unset, false or true the refspec on the
command-line overrides any configuration variable.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch tests: add a tag to be deleted to the pruning tests
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:06 +0000 (20:32 +0000)]
fetch tests: add a tag to be deleted to the pruning tests

Add a tag to be deleted to the fetch --prune tests. The tag is always
kept for now, which is the expected behavior, but now I can add a test
for tag pruning in a later commit.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch tests: re-arrange arguments for future readability
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:05 +0000 (20:32 +0000)]
fetch tests: re-arrange arguments for future readability

Re-arrange the arguments to the test_configured_prune() function used
in this test to pass the arguments to --fetch last. A subsequent
change will test for more elaborate fetch arguments, including long
refspecs. It'll be more readable to be able to wrap those on a new
line of their own.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch tests: refactor in preparation for testing tag pruning
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:04 +0000 (20:32 +0000)]
fetch tests: refactor in preparation for testing tag pruning

In a subsequent commit this function will learn to test for tag
pruning, prepare for that by making space for more variables, and
making it clear that "expected" here refers to branches.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoremote: add a macro for "refs/tags/*:refs/tags/*"
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:03 +0000 (20:32 +0000)]
remote: add a macro for "refs/tags/*:refs/tags/*"

Add a macro with the refspec string "refs/tags/*:refs/tags/*". There's
been a pre-defined struct version of this since e0aaa29ff3 ("Have a
constant extern refspec for "--tags"", 2008-04-17), but nothing that
could be passed to e.g. add_fetch_refspec().

This will be used in subsequent commits to avoid hardcoding this
string in multiple places.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch: stop accessing "remote" variable indirectly
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:02 +0000 (20:32 +0000)]
fetch: stop accessing "remote" variable indirectly

Access the "remote" variable passed to the fetch_one() directly rather
than through the gtransport wrapper struct constructed in this
function for other purposes.

This makes the code more readable, as it's now obvious that the remote
struct doesn't somehow get munged by the prepare_transport() function
above, which takes the "remote" struct as an argument and constructs
the "gtransport" struct, containing among other things the "remote"
struct.

A subsequent change will copy this pattern to access a new
remote->prune_tags field, but without the use of the gtransport
variable. It's useful once that change lands to see that the two
pieces of code behave exactly the same.

This pattern of accessing the container struct was added in
737c5a9cde ("fetch: make --prune configurable", 2013-07-13) when this
code was initially introduced.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch: trivially refactor assignment to ref_nr
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:01 +0000 (20:32 +0000)]
fetch: trivially refactor assignment to ref_nr

Trivially refactor an assignment to make a subsequent patch
smaller. The "ref_nr" variable is initialized to 0 earlier, just as
"j" is, and "j" is only incremented in that loop, so this change isn't
a logic error.

This change simplifies a subsequent change, which will split the
incrementing of "ref_nr" into two blocks.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agofetch: don't redundantly NULL something calloc() gave us
Ævar Arnfjörð Bjarmason [Fri, 9 Feb 2018 20:32:00 +0000 (20:32 +0000)]
fetch: don't redundantly NULL something calloc() gave us

Stop redundantly NULL-ing the last element of the refs structure,
which was retrieved via calloc(), and is thus guaranteed to be
pre-NULL'd.

This code dates back to b888d61c83 ("Make fetch a builtin",
2007-09-10), where wasn't any reason to do this back then either, it's
just boilerplate left over from when git-fetch was initially
introduced.

The motivation for this change was to make a subsequent change which
would also modify the refs variable smaller, since it won't have to
copy this redundant "NULL the last + 1 item" pattern.

We may not end up keeping that change, but as this pattern is still
pointless, so let's fix it.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agohash: update obsolete reference to SHA1_HEADER
brian m. carlson [Thu, 8 Feb 2018 02:48:58 +0000 (02:48 +0000)]
hash: update obsolete reference to SHA1_HEADER

We moved away from SHA1_HEADER to a preprocessor if chain, but didn't
update the comment discussing the platform defines.  Update this comment
so it reflects the current state of our codebase.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agorebase -p: fix incorrect commit message when calling `git merge`.
Gregory Herrero [Thu, 8 Feb 2018 20:42:41 +0000 (21:42 +0100)]
rebase -p: fix incorrect commit message when calling `git merge`.

Since commit dd6fb0053 ("rebase -p: fix quoting when calling `git
merge`"), commit message of the merge commit being rebased is passed to
the merge command using a subshell executing 'git rev-parse --sq-quote'.

Double quotes are needed around this subshell so that, newlines are
kept for the git merge command.

Before this patch, following merge message:

    "Merge mybranch into mynewbranch

    Awesome commit."

becomes:

    "Merge mybranch into mynewbranch Awesome commit."

after a rebase -p.

Fixes: "dd6fb0053 rebase -p: fix quoting when calling `git merge`"
Reported-by: Jamie Iles <jamie.iles@oracle.com>
Suggested-by: Vegard Nossum <vegard.nossum@oracle.com>
Suggested-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Signed-off-by: Gregory Herrero <gregory.herrero@oracle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoCodingGuidelines: mention "static" and "extern"
Jeff King [Thu, 8 Feb 2018 21:38:06 +0000 (16:38 -0500)]
CodingGuidelines: mention "static" and "extern"

It perhaps goes without saying that file-local stuff should
be marked static, but it does not hurt to remind people.

Less obvious is that we are settling on "do not include
extern in function declarations". It is already the default
unless the function was previously declared static (but if
you are following a static declaration with an unmarked one,
you should think about why you are declaring the thing
twice). And so it just becomes an extra noise-word in our
header files.

We used to give the opposite advice, so there are quite a
few "extern" markers in early Git code. But this at least
makes a concrete suggestion that we can follow going
forward.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoalways check for NULL return from packet_read_line()
Jon Simons [Thu, 8 Feb 2018 18:47:50 +0000 (13:47 -0500)]
always check for NULL return from packet_read_line()

The packet_read_line() function will die if it sees any
protocol or socket errors. But it will return NULL for a
flush packet; some callers which are not expecting this may
dereference NULL if they get an unexpected flush. This would
involve the other side breaking protocol, but we should
flag the error rather than segfault.

Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agocorrect error messages for NULL packet_read_line()
Jeff King [Thu, 8 Feb 2018 18:47:49 +0000 (13:47 -0500)]
correct error messages for NULL packet_read_line()

The packet_read_line() function dies if it gets an
unexpected EOF. It only returns NULL if we get a flush
packet (or technically, a zero-length "0004" packet, but
nobody is supposed to send those, and they are
indistinguishable from a flush in this interface).

Let's correct error messages which claim an unexpected EOF;
it's really an unexpected flush packet.

While we're here, let's also check "!line" instead of
"!len" in the second case. The two events should always
coincide, but checking "!line" makes it more obvious that we
are not about to dereference NULL.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoname-hash: properly fold directory names in adjust_dirname_case()
Ben Peart [Thu, 8 Feb 2018 19:23:33 +0000 (14:23 -0500)]
name-hash: properly fold directory names in adjust_dirname_case()

Correct the pointer arithmetic in adjust_dirname_case() so that it calls
find_dir_entry() with the correct string length.  Previously passing in
"dir1/foo" would pass a length of 6 instead of the correct 4.  This resulted in
find_dir_entry() never finding the entry and so the subsequent memcpy that would
fold the name to the version with the correct case never executed.

Add a test to validate the corrected behavior with name folding of directories.

Signed-off-by: Ben Peart <benpeart@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot: make 'test_i18ngrep' more informative on failure
SZEDER Gábor [Thu, 8 Feb 2018 15:56:56 +0000 (16:56 +0100)]
t: make 'test_i18ngrep' more informative on failure

When 'test_i18ngrep' can't find the expected pattern, it exits
completely silently; when its negated form does find the pattern that
shouldn't be there, it prints the matching line(s) but otherwise exits
without any error message.  This leaves the developer puzzled about
what could have gone wrong.

Make 'test_i18ngrep' more informative on failure by printing an error
message including the invoked 'grep' command and the contents of the
file it had to scan through.

Note that this "dump the scanned file" part is not quite perfect, as
it dumps only the file specified as the function's last positional
parameter, thus assuming that there is only a single file parameter.
I think that's a reasonable assumption to make, one that holds true in
the current code base.  And even if someone were to scan multiple
files at once in the future, the worst thing that could happen is that
the verbose error message won't include the contents of all those
files, only the last one.  Alas, we can't really do any better than
this, because checking whether the other positional parameters match a
filename can result in false positives: 't3400-rebase.sh' and
't3404-rebase-interactive.sh' contain one test each, where the
'test_i18ngrep's pattern verbatimly matches a file in the trash
directory.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot: validate 'test_i18ngrep's parameters
SZEDER Gábor [Thu, 8 Feb 2018 15:56:55 +0000 (16:56 +0100)]
t: validate 'test_i18ngrep's parameters

Some of the previous patches in this series fixed bogus
'test_i18ngrep' invocations:

  - Two invocations where the tested git command's standard output is
    directly piped into 'test_i18ngrep'.  While convenient, this is an
    antipattern, because the pipe hides the git command's exit code,
    and the test could continue even if the command exited with error.

  - Two invocations that had neither a filename parameter nor anything
    piped into their standard input, yet both managed to remain
    unnoticed for years.  A third similarly bogus invocation is
    currently lurking in 'pu' for a couple of weeks now.

Prevent similar mistakes in the future by validating 'test_i18ngrep's
parameters requiring that

  - The last parameter names an existing file to be read, effectively
    forbidding piping into 'test_i18ngrep'.

    Note that this change will also forbid cases where 'test_i18ngrep'
    would legitimately read its standard input, e.g. when its standard
    input is redirected from a file, or when a git command's standard
    output is first written to an intermediate file, which is then
    preprocessed by a non-git command before the results are piped
    into 'test_i18ngrep'.  See two of the previous patches for the
    only such cases we had in our test suite.  However, reliably
    preventing the piping antipattern is arguably more important than
    supporting these cases, which can be easily worked around by
    opening the file directly or using an intermediate file anyway.

  - There are at least two parameters, not including the optional '!'
    to negate the pattern.  This ought to catch corner cases when
    'test_i18ngrep' looks for the name of an existing file on its
    standard input; the above check would miss this case becase the
    filename as pattern would be the last parameter.

    Note that this is not quite perfect, as it doesn't account for any
    'grep --options' given as parameters.  However, doing so would be
    far too complicated, considering that patterns can start with
    dashes as well, and in the majority of the cases we don't use any
    such options anyway.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh'
SZEDER Gábor [Thu, 8 Feb 2018 15:56:54 +0000 (16:56 +0100)]
t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh'

Both 'test_i18ncmp' and 'test_i18ngrep' helper functions are supposed
to be called from our test scripts, so they should be in
'test-lib-functions.sh'.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot5536: let 'test_i18ngrep' read the file without redirection
SZEDER Gábor [Thu, 8 Feb 2018 15:56:53 +0000 (16:56 +0100)]
t5536: let 'test_i18ngrep' read the file without redirection

Redirecting 'test_i18ngrep's standard input from a file will interfere
with the linting that will be added in a later patch.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot5510: consolidate 'grep' and 'test_i18ngrep' patterns
SZEDER Gábor [Thu, 8 Feb 2018 15:56:52 +0000 (16:56 +0100)]
t5510: consolidate 'grep' and 'test_i18ngrep' patterns

One of the tests in 't5510-fetch.sh' checks the output of 'git fetch'
using 'test_i18ngrep', and while doing so it prefilters the output
with 'grep' before piping the result into 'test_i18ngrep'.

This prefiltering is unnecessary, with the appropriate pattern
'test_i18ngrep' can do it all by itself.  Furthermore, piping data
into 'test_i18ngrep' will interfere with the linting that will be
added in a later patch.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot4001: don't run 'git status' upstream of a pipe
SZEDER Gábor [Thu, 8 Feb 2018 15:56:51 +0000 (16:56 +0100)]
t4001: don't run 'git status' upstream of a pipe

The primary purpose of three tests in 't4001-diff-rename.sh' is to
check rename detection in 'git status', but all three do so by running
'git status' upstream of a pipe, hiding its exit code.  Consequently,
the test could continue even if 'git status' exited with error.

Use an intermediate file between 'git status' and 'test_i18ngrep' to
catch a potential failure of the former.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot6022: don't run 'git merge' upstream of a pipe
SZEDER Gábor [Thu, 8 Feb 2018 15:56:50 +0000 (16:56 +0100)]
t6022: don't run 'git merge' upstream of a pipe

The primary purpose of 't6022-merge-rename.sh' is to test 'git merge',
but one of the tests runs it upstream of a pipe, hiding its exit code.
Consequently, the test could continue even if 'git merge' exited with
error.

Use an intermediate file between 'git merge' and 'test_i18ngrep' to
catch a potential failure of the former.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot5812: add 'test_i18ngrep's missing filename parameter
SZEDER Gábor [Thu, 8 Feb 2018 15:56:49 +0000 (16:56 +0100)]
t5812: add 'test_i18ngrep's missing filename parameter

The second 'test_i18ngrep' invocation in the test 'curl redirects
respect whitelist' is missing its filename parameter.  This has
remained unnoticed since its introduction in f4113cac0 (http: limit
redirection to protocol-whitelist, 2015-09-22), because it would only
cause the test to fail if Git was built with a sufficiently old
libcurl version.  The test's two ||-chained 'test_i18ngrep'
invocations are supposed to check that either one of the two patterns
is present in 'git clone's error message.  As it happens, the first
invocation covers the error message from any reasonably up-to-date
libcurl, thus the second invocation, the one without the filename
parameter, isn't executed at all.  Apparently no one has run the test
suite's httpd tests with such an old libcurl in the last 2+ years, or
at least they haven't bothered to notify us about the failed test.

Fix this by consolidating the two patterns into a single extended
regexp, eliminating the need for an ||-chained second 'test_i18ngrep'
invocation.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot5541: add 'test_i18ngrep's missing filename parameter
SZEDER Gábor [Thu, 8 Feb 2018 15:56:48 +0000 (16:56 +0100)]
t5541: add 'test_i18ngrep's missing filename parameter

The test 'push --no-progress silences progress but not status' runs
'test_i18ngrep' without specifying a filename parameter.  This has
remained unnoticed since its introduction in e304aeba2 (t5541: test
more combinations of --progress, 2012-05-01), because that
'test_i18ngrep' is supposed to check that the given pattern is not
present in its input, and of course it won't find that pattern if its
input is empty (as it comes from /dev/null).  This also means that
this test could miss a potential breakage of 'git push --no-progress'.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agogit-sh-i18n: check GETTEXT_POISON before USE_GETTEXT_SCHEME
Jeff King [Tue, 6 Feb 2018 08:44:56 +0000 (03:44 -0500)]
git-sh-i18n: check GETTEXT_POISON before USE_GETTEXT_SCHEME

Running "make NO_GETTEXT=1 GETTEXT_POISON=1" currently fails
t0205.

While it might seem nonsensical at first glance to both
poison and disable gettext, it's useful to be able to do a
poison test-run on a system that doesn't have gettext at
all. And it works fine for C programs; the problem is only
with the shell code.

The issue is that we check the baked-in USE_GETTEXT_SCHEME
value before GETTEXT_POISON. And when NO_GETTEXT is set, the
Makefile sets USE_GETTEXT_SCHEME to "fallthrough".

So one fix would be to have the Makefile just set
USE_GETTEXT_SCHEME to "poison" if GETTEXT_POISON is set.
But there are two problems with that:

  1. USE_GETTEXT_SCHEME is actually a user-facing knob, so
     conceivably somebody could override it with:

       make USE_GETTEXT_SCHEME=gnu GETTEXT_POISON=1

     which would do the wrong thing (though that's much less
     likely than them having the variable set in their
     config.mak and just overriding GETTEXT_POISON on the
     command-line for a one-off test).

  2. We don't actually bake GETTEXT_POISON in to the shell
     library like we do for the C code. It checks
     $GIT_GETTEXT_POISON at runtime, which is set up by the
     test suite. So it makes sense to put the fix in the
     runtime code, too, which would cover something like:

       GIT_GETTEXT_POISON=foo git foo

     It's not likely that people use the poison code outside
     of running the test suite, but it's easy enough to make
     this case work.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot0205: drop redundant test
Jeff King [Tue, 6 Feb 2018 08:43:19 +0000 (03:43 -0500)]
t0205: drop redundant test

We check that a shell variable is non-empty, and then we
check that it's equal to a particular value. Just checking
the latter covers both cases.

I suspect the original was trying to give better output when
the test fails, but using "-x" covers that these days.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agotag: add --edit option
Nicolas Morey-Chaisemartin [Tue, 6 Feb 2018 08:36:24 +0000 (09:36 +0100)]
tag: add --edit option

Add a --edit option whichs allows modifying the messages provided by -m or -F,
the same way git commit --edit does.

Signed-off-by: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@suse.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agoblame: tighten command line parser
Junio C Hamano [Mon, 5 Feb 2018 23:12:11 +0000 (15:12 -0800)]
blame: tighten command line parser

The command line parser of "git blame" is prepared to take an
ancient odd argument order "blame <path> <rev>" in addition to the
usual "blame [<rev>] <path>".  It has at least two negative
ramifications:

 - In order to tell these two apart, it checks if the last command
   line argument names a path in the working tree, using
   file_exists().  However, "blame <rev> <path>" is a request to
   explain each and every line in the contents of <path> stored in
   revision <rev> and does not need to have a working tree version
   of the file.  A check with file_exists() is simply wrong.

 - To coerce that mistaken file_exists() check to work, the code
   calls setup_work_tree() before doing so, because the path it has
   is relative to the top-level of the project tree.  However,
   "blame <rev> <path>" MUST be usable even in a bare repository,
   and there is no reason for letting setup_work_tree() complain
   and die with "This operation must be run in a work tree".

To correct the former, switch to check if the last token is a
revision (and if so, parse arguments using "blame <path> <rev>"
rule).  Correct the latter by getting rid of setup_work_tree() and
file_exists() check--the only case the call to this function matters
is when we are running "blame <path>" (i.e. no starting revision and
asking to blame the working tree file at <path>, digging through the
HEAD revision), but there is a call in setup_scoreboard() just
before it calls fake_working_tree_commit().

Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agodir.c: ignore paths containing .git when invalidating untracked cache
Nguyễn Thái Ngọc Duy [Wed, 7 Feb 2018 09:21:40 +0000 (16:21 +0700)]
dir.c: ignore paths containing .git when invalidating untracked cache

read_directory() code ignores all paths named ".git" even if it's not
a valid git repository. See treat_path() for details. Since ".git" is
basically invisible to read_directory(), when we are asked to
invalidate a path that contains ".git", we can safely ignore it
because the slow path would not consider it anyway.

This helps when fsmonitor is used and we have a real ".git" repo at
worktree top. Occasionally .git/index will be updated and if the
fsmonitor hook does not filter it, untracked cache is asked to
invalidate the path ".git/index".

Without this patch, we invalidate the root directory unncessarily,
which:

- makes read_directory() fall back to slow path for root directory
  (slower)

- makes the index dirty (because UNTR extension is updated). Depending
  on the index size, writing it down could also be slow.

A note about the new "safe_path" knob. Since this new check could be
relatively expensive, avoid it when we know it's not needed. If the
path comes from the index, it can't contain ".git". If it does
contain, we may be screwed up at many more levels, not just this one.

Noticed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agomv: remove unneeded 'if (!show_only)'
Stefan Moch [Sun, 31 Dec 2017 19:11:56 +0000 (20:11 +0100)]
mv: remove unneeded 'if (!show_only)'

Commit a127331cd (mv: allow moving nested submodules,
2016-04-19), introduced

    if (show_only) continue;

in this for-loop before

    if (!show_only)

which became redundant, because it is now always true.

Signed-off-by: Stefan Moch <stefanmoch@mail.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agot7001: add test case for --dry-run
Stefan Moch [Sun, 31 Dec 2017 19:11:55 +0000 (20:11 +0100)]
t7001: add test case for --dry-run

Make sure that "git mv --dry-run" does not move file.

Signed-off-by: Stefan Moch <stefanmoch@mail.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agorebase: add --allow-empty-message option
Genki Sky [Sun, 4 Feb 2018 20:08:13 +0000 (15:08 -0500)]
rebase: add --allow-empty-message option

This option allows commits with empty commit messages to be rebased,
matching the same option in git-commit and git-cherry-pick. While empty
log messages are frowned upon, sometimes one finds them in older
repositories (e.g. translated from another VCS [0]), or have other
reasons for desiring them. The option is available in git-commit and
git-cherry-pick, so it is natural to make other git tools play nicely
with them. Adding this as an option allows the default to be "give the
user a chance to fix", while not interrupting the user's workflow
otherwise [1].

  [0]: https://stackoverflow.com/q/8542304
  [1]: https://public-inbox.org/git/7vd33afqjh.fsf@alter.siamese.dyndns.org/

To implement this, add a new --allow-empty-message flag. Then propagate
it to all calls of 'git commit', 'git cherry-pick', and 'git rebase--helper'
within the rebase scripts.

Signed-off-by: Genki Sky <sky@genki.is>
Reviewed-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agodaemon: add --log-destination=(stderr|syslog|none)
Lucas Werkmeister [Sun, 4 Feb 2018 18:30:37 +0000 (19:30 +0100)]
daemon: add --log-destination=(stderr|syslog|none)

This new option can be used to override the implicit --syslog of
--inetd, or to disable all logging. (While --detach also implies
--syslog, --log-destination=stderr with --detach is useless since
--detach disassociates the process from the original stderr.) --syslog
is retained as an alias for --log-destination=syslog.

--log-destination always overrides implicit --syslog regardless of
option order. This is different than the “last one wins” logic that
applies to some implicit options elsewhere in Git, but should hopefully
be less confusing. (I also don’t know if *all* implicit options in Git
follow “last one wins”.)

The combination of --inetd with --log-destination=stderr is useful, for
instance, when running `git daemon` as an instanced systemd service
(with associated socket unit). In this case, log messages sent via
syslog are received by the journal daemon, but run the risk of being
processed at a time when the `git daemon` process has already exited
(especially if the process was very short-lived, e.g. due to client
error), so that the journal daemon can no longer read its cgroup and
attach the message to the correct systemd unit (see systemd/systemd#2913
[1]). Logging to stderr instead can solve this problem, because systemd
can connect stderr directly to the journal daemon, which then already
knows which unit is associated with this stream.

[1]: https://github.com/systemd/systemd/issues/2913

Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Lucas Werkmeister <mail@lucaswerkmeister.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years agococci: simplify check for trivial format strings
René Scharfe [Thu, 1 Feb 2018 18:56:34 +0000 (19:56 +0100)]
cocci: simplify check for trivial format strings

353d84c537 (coccicheck: make transformation for strbuf_addf(sb, "...")
more precise) added a check to avoid transforming calls with format
strings which contain percent signs, as that would change the result.
It uses embedded Python code for that.  Simplify this rule by using the
regular expression matching operator instead.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>