[00/15] SHA-256 test fixes, part 6

Message

brian m. carlson Oct. 5, 2019, 9:11 p.m. UTC

This series consists mostly of additional test fixes for SHA-256, plus
some test framework improvements and a new option to rev-parse.

Up until now, most of the test changes have been directly related to
fixing hash values or sizes in some way.  In other words, previous test
fixes would be required even for a Git binary that supported only
SHA-256 and not SHA-1.

In this series, we also introduce some test changes that deal with the
extension that will allow the same binary to handle both.  The changes
themselves are relatively uninteresting, but changes like these will be
making appearances in future test fix series as well.  They may appear
bizarre and out of place at times, but rest assured that they will be
useful in the future.

The other notable thing in this series is the introduction of a new
rev-parse option, --object-format.  We know, according to the transition
plan, that we'll need to support users working with input and output
in different hash algorithms.  Since we're starting to see this kind of
code appear in the codebase, it makes sense to introduce a helper that
lets scripters determine the appropriate value, and we should introduce
this code sooner, rather than later, so people can start using it.

We had had some discussions about the name of options to be used for
hash algorithms but I don't recall us coming to a definitive conclusion.
Opinions about the name[0] are of course welcome.  I'm not particularly
attached to any name, so whatever the consensus is works for me.

[0] Possibilities include --object-format, --show-object-format, --hash,
--show-hash, --hash-algorithm, --show-hash-algorithm, and more.

brian m. carlson (15):
  t/oid-info: allow looking up hash algorithm name
  t/oid-info: add empty tree and empty blob values
  rev-parse: add an --object-format option
  t1305: avoid comparing extensions
  t3429: remove SHA1 annotation
  t4010: abstract away SHA-1-specific constants
  t4011: abstract away SHA-1-specific constants
  t4015: abstract away SHA-1-specific constants
  t4027: make hash-size independent
  t4034: abstract away SHA-1-specific constants
  t4038: abstract away SHA-1 specific constants
  t4039: abstract away SHA-1-specific constants
  t4044: update test to work with SHA-256
  t4045: make hash-size independent
  t4048: abstract away SHA-1-specific constants

 Documentation/git-rev-parse.txt     |  7 +++
 builtin/rev-parse.c                 | 11 ++++
 t/oid-info/hash-info                |  9 +++
 t/t1305-config-include.sh           |  2 +-
 t/t1500-rev-parse.sh                | 15 +++++
 t/t3429-rebase-edit-todo.sh         |  2 +-
 t/t4010-diff-pathspec.sh            | 20 ++++---
 t/t4011-diff-symlink.sh             | 31 ++++++----
 t/t4015-diff-whitespace.sh          | 89 ++++++++++++++++-----------
 t/t4027-diff-submodule.sh           | 16 ++---
 t/t4034-diff-words.sh               | 93 +++++++++++++++++------------
 t/t4038-diff-combined.sh            | 19 ++++--
 t/t4039-diff-assume-unchanged.sh    |  3 +-
 t/t4044-diff-index-unique-abbrev.sh | 46 +++++++++-----
 t/t4045-diff-relative.sh            |  2 +-
 t/t4048-diff-combined-binary.sh     | 58 ++++++++++--------
 16 files changed, 268 insertions(+), 155 deletions(-)

Comments

Derrick Stolee Oct. 8, 2019, 12:40 p.m. UTC | #1

On 10/5/2019 5:11 PM, brian m. carlson wrote:
> This series consists mostly of additional test fixes for SHA-256, plus
> some test framework improvements and a new option to rev-parse.
> 
> Up until now, most of the test changes have been directly related to
> fixing hash values or sizes in some way.  In other words, previous test
> fixes would be required even for a Git binary that supported only
> SHA-256 and not SHA-1.
> 
> In this series, we also introduce some test changes that deal with the
> extension that will allow the same binary to handle both.  The changes
> themselves are relatively uninteresting, but changes like these will be
> making appearances in future test fix series as well.  They may appear
> bizarre and out of place at times, but rest assured that they will be
> useful in the future.
> 
> The other notable thing in this series is the introduction of a new
> rev-parse option, --object-format.  We know, according to the transition
> plan, that we'll need to support users working with input and output
> in different hash algorithms.  Since we're starting to see this kind of
> code appear in the codebase, it makes sense to introduce a helper that
> lets scripters determine the appropriate value, and we should introduce
> this code sooner, rather than later, so people can start using it.
> 
> We had had some discussions about the name of options to be used for
> hash algorithms but I don't recall us coming to a definitive conclusion.
> Opinions about the name[0] are of course welcome.  I'm not particularly
> attached to any name, so whatever the consensus is works for me.
> 
> [0] Possibilities include --object-format, --show-object-format, --hash,
> --show-hash, --hash-algorithm, --show-hash-algorithm, and more.
Outside of a question regarding using a test-tool instead of adding an
option to 'git rev-parse', I found this series very readable.

My confusion around the printf|git hash-object stuff that is now
resolved. The error was in my reading, not in the presentation.

Thanks for your continued hard work on this subject!

-Stolee