delta/git.git/builtin/hash-object.c, branch v2.37.6

Merge branch 'ab/object-file-api-updates'

2022-03-17T00:53:08+00:00

Object-file API shuffling.

* ab/object-file-api-updates:
  object-file API: pass an enum to read_object_with_reference()
  object-file.c: add a literal version of write_object_file_prepare()
  object-file API: have hash_object_file() take "enum object_type"
  object API: rename hash_object_file_literally() to write_*()
  object-file API: split up and simplify check_object_signature()
  object API users + docs: check <0, not !0 with check_object_signature()
  object API docs: move check_object_signature() docs to cache.h
  object API: correct "buf" v.s. "map" mismatch in *.c and *.h
  object-file API: have write_object_file() take "enum object_type"
  object-file API: add a format_object_header() function
  object-file API: return "void", not "int" from hash_object_file()
  object-file.c: split up declaration of unrelated variables

object API: rename hash_object_file_literally() to write_*()

2022-02-26T01:16:32+00:00

Before 0c3db67cc81 (hash-object --literally: fix buffer overrun with
extra-long object type, 2015-05-04) the hash-object code being changed
here called write_sha1_file() to both hash and write a loose
object. Before that we'd use hash_sha1_file() to if "-w" wasn't
provided, and otherwise call write_sha1_file().

Now we'll always call the same function for both writing. Let's rename
it from hash_*_literally() to write_*_literally(). Even though the
write_*() might not actually write if HASH_WRITE_OBJECT isn't in
"flags", having it be more similar to write_object_file_flags() than
hash_object_file(), but carrying a name that would suggest that it's a
variant of the latter is confusing.

Signed-off-by: Ævar Arnfjörð Bjarmason 
Signed-off-by: Junio C Hamano

Merge branch 'ja/i18n-common-messages'

2022-02-25T23:47:35+00:00

Unify more messages to help l10n.

* ja/i18n-common-messages:
  i18n: fix some misformated placeholders in command synopsis
  i18n: remove from i18n strings that do not hold translatable parts
  i18n: factorize "invalid value" messages
  i18n: factorize more 'incompatible options' messages

hash-object: fix a trivial leak in --path

2022-02-07T01:55:55+00:00

Fix a memory leak that happened when the --path option was
provided. This leak has been with us ever since the option was added
in 39702431500 (add --path option to git hash-object, 2008-08-03).

We can now mark "t1007-hash-object.sh" as passing when git is compiled
with SANITIZE=leak. It'll now run in the the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).

Signed-off-by: Ævar Arnfjörð Bjarmason 
Signed-off-by: Junio C Hamano

i18n: remove from i18n strings that do not hold translatable parts

2022-02-04T21:58:28+00:00

Signed-off-by: Jean-Noël Avila 
Signed-off-by: Junio C Hamano

Merge branch 'jc/prefix-filename-allocates'

2021-09-15T20:15:28+00:00

Leakfix.

* jc/prefix-filename-allocates:
  hash-object: prefix_filename() returns allocated memory these days

hash-object: prefix_filename() returns allocated memory these days

2021-09-07T22:18:59+00:00

Back when a1be47e4 (hash-object: fix buffer reuse with --path in a
subdirectory, 2017-03-20) was written, the prefix_filename() helper
used a static piece of memory to the caller, making the caller
responsible for copying it, if it wants to keep it across another
call to the same function.  Two callers of the prefix_filename() in
hash-object were made to xstrdup() the value obtained from it.

But in the same series, when e4da43b1 (prefix_filename: return newly
allocated string, 2017-03-20) changed the rule to gave the caller
possession of the memory, we forgot to revert one of the xstrdup()
changes, allowing the returned value to leak.

Signed-off-by: Junio C Hamano

use xopen() to handle fatal open(2) failures

2021-08-25T21:39:08+00:00

Add and apply a semantic patch for using xopen() instead of calling
open(2) and die() or die_errno() explicitly.  This makes the error
messages more consistent and shortens the code.

Signed-off-by: René Scharfe 
Signed-off-by: Junio C Hamano

builtin: consistently pass cmd_* prefix to parse_options

2019-05-13T05:22:53+00:00

If a builtin uses RUN_SETUP to request that git.c enter the repository
directory, we'll get passed in a "prefix" variable with the path to the
original directory.  It's important to pass this to parse_options(),
since we may use it to fix up relative OPT_FILENAME() options. Some
builtins don't bother; let's make sure we do so consistently.

There may not be any particular bugs fixed here; OPT_FILENAME is
actually pretty rare, and none of these commands use it directly.
However, this does future-proof us against somebody adding an option
that uses it and creating a subtle bug that only shows up when you're in
a subdirectory of the repository.

In some cases, like hash-object and upload-pack, we don't specify
RUN_SETUP, so we know the prefix will always be empty. It's still worth
passing the variable along to keep the idiom consistent across all
builtins (and of course it protects us if they ever _did_ switch to
using RUN_SETUP).

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch

2019-01-24T19:55:06+00:00

By default, index compat macros are off from now on, because they
could hide the_index dependency.

Only those in builtin can use it.

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano