function in use.
Signed-off-by: brian m. carlson
---
t/test-lib-functions.sh | 40
t/translate/hash-info | 9 +
t/translate/oid | 15 +++
3 files changed, 64 insertions(+)
create mode 100644 t/translate/hash-info
create mode
If the hash we're using is 32 bytes in size, attempting to insert a
20-byte object name won't work. Since these are synthesized objects
that are almost all zeros, look them up in a translation table.
Signed-off-by: brian m. carlson
---
t/t-basic.sh | 13 +++--
1 file
ome exceptions, covered in t/README).
This was exactly my reasoning.
> > > + if [ "$1" = "-f" ]
> >
> > Style nit, please avoid [] and use test:
> > if test "$1" = "-f"
>
> This I agree with. :)
Yeah, I forgot that that's our style. I'll fix that.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
bcdef0123456789' QN0 <"$3" >"$act" &&
> test_cmp "$exp" "$act" &&
> rm "$exp" "$act"
> }
>
> In the long term the 'tr' may need an additional 'sed' expression.
I'll take a look. That may end up being a more robust solution.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
lability of
implementations, performance, and other attributes described in the
transition plan and can send that to the list.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
-512/256,
and SHA3-256 should be available in the near future on a reasonably
small Debian, Ubuntu, or Fedora install.
As far as security, the most conservative choices appear to be SHA-256,
SHA-512/256, and SHA3-256.
The performance winners are BLAKE2b unaccelerated and SHA-256 accelerated.
--
but a persistently enabled feature is not.
I expect this feature, if implemented, would be patched out of Debian's
Git, and it would be patched out of any Git I would distribute in my
work role for legal and ethical reasons.
As developers, we have a duty to be mindful of how our software c
't work if the mode changes and we're not the
owner of the file. One place where I could see people wanting to use
this on Unix is shared repositories with BSD group semantics, but that
wouldn't work reliably.
I don't see that as a problem, as that isn't the issue this patch is
trying to solve, but it may end up biting people.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
On Mon, Jun 11, 2018 at 12:29:42PM -0700, Jonathan Nieder wrote:
> brian m. carlson wrote:
>
> > == Discussion of Candidates
> >
> > I've implemented and tested the following algorithms, all of which are
> > 256-bit (in alphabetical order):
>
> Tha
On Mon, Jun 11, 2018 at 03:47:43AM -0400, Eric Sunshine wrote:
> On Mon, Jun 04, 2018 at 11:52:20PM +0000, brian m. carlson wrote:
> > Add a test function helper, test_translate, that will produce its first
> > argument if the hash in use is SHA-1 and the second if its argument
On Mon, Jun 11, 2018 at 04:09:05AM -0400, Eric Sunshine wrote:
> On Mon, Jun 4, 2018 at 7:52 PM, brian m. carlson
> wrote:
> > test_expect_success 'lookup with almost duplicate values' '
> > + # n-1 5s
> > + root=$(test_translate
ler. Now it still probably can optimize the memcmp(,,20),
> but we stack another indirect function call on top. I guess I might be
> just paranoid and this is not a big deal after all.
I would have to run some numbers on this. I probably won't get around
to doing that until Friday or
On Mon, Jun 11, 2018 at 12:01:03PM -0700, Jonathan Nieder wrote:
> Hi,
>
> brian m. carlson wrote:
> > I plan on introducing an array of hash algorithms into struct repository
> > (and wrapper macros) which stores, in order, the output hash, and if
> > used
On Tue, Jun 12, 2018 at 06:21:21PM +0200, Gilles Van Assche wrote:
> Hi,
>
> On 10/06/18 00:49, brian m. carlson wrote:
> > I imported the optimized 64-bit implementation of KangarooTwelve. The
> > AVX2 implementation was not considered for licensing reasons (it's
&g
On Tue, Jun 12, 2018 at 03:29:47AM -0400, Eric Sunshine wrote:
> On Mon, Jun 11, 2018 at 9:05 PM, brian m. carlson
> wrote:
> > test_oid would be fine. One note is that this doesn't always produce
> > OIDs; sometimes it will produce other values, but as long as you don
dded, it would require some reworking of the auth code.
You are, of course, welcome to send a patch.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
On Thu, Jun 14, 2018 at 11:15:07AM -0400, Jeff King wrote:
> On Thu, Jun 14, 2018 at 10:13:42AM +0000, brian m. carlson wrote:
> > There isn't any support for Bearer authentication in Git. For HTTP, we
> > use libcurl, which doesn't provide this natively. While it cou
ld simply not be viable with an unaccelerated SHA-256 or SHA3-256,
although it would perform reasonably well with BLAKE2b.
Having said that, I'd be happy with any of the three, and would support
a consensus around any of them as well.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
Git doesn't have
attributes that are conditional on the platform in that sort of way.
You could use a smudge/clean filter and adjust the filter for the
platform you're on, which might meet your needs.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
rr if no current commit could be determined,
> and might scare the occasional developer who simply tries to build Git
> from scratch.
I saw that building Git 2.18.0 for $DAYJOB. Thanks for fixing it.
The series looked good to me, too.
--
brian m. carlson: Houston, Texas, US
OpenP
s across a
wide variety of system may be non-trivial. This is less of a problem
with UTF-8, but having the ability to pick an encoding and remap it to a
supported value may be useful nevertheless.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
stfix to do so because being strict on mail standards is a
great way to stop spam.
If that's the issue you're seeing, it might be better to either
automatically encode those patches as binary patches or teach git
send-email and git am how to automatically handle quoted-printabl
On Sun, Jul 01, 2018 at 08:17:53PM -0400, Drew DeVault wrote:
> On 2018-07-01 6:15 PM, brian m. carlson wrote:
> > Are you suggesting that we not limit lines to 998 octets? I've seen
> > lots of mail servers that do reject mail over 998 octets. I've
> > configured
of signatures.
We typically prefer to have option values specified in lower case. I
also think "openpgp" might be better than "PGP", since that's the name
of the specification and it would avoid any potential unhappiness about
compatibility with PGP or trademarks.
-
"PGP", .program = "gpg",
> .extra_args_verify = { "--keyid-format=long", },
> .sigs = { PGP_SIGNATURE, PGP_MESSAGE, },
> },
> + { .format = "X509", .program = "gpgsm",
Similarly to my comment about "PGP", I think this would do well as
"x509".
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
| tr -d '\n' > ${GNUPGHOME}/trustlist.txt &&
> + echo " S relax" >> ${GNUPGHOME}/trustlist.txt &&
> + (gpgconf --kill gpg-agent >/dev/null 2>&1 || : ) &&
> + echo hello | gpgsm --homedir
iginal series aimed at being generic for any sort of signing tool, while
> this series just introduced the X509 variant of gpg. (gpgsm)
> I collected authors and reviewers of that first series and already put them
> on cc.
Overall, I think this is heading in a good direction. I left a few
.
Add a transfer encoding value, auto, which indicates that a patch should
use 8bit where allowed and quoted-printable otherwise. Choose
quoted-printable instead of base64, since base64-encoded plain text is
treated as suspicious by some spam filters.
Signed-off-by: brian m. carlson
ill cause any
problems, but if someone knows of a reason why it would, please shout
loudly.
brian m. carlson (3):
send-email: add an auto option for transfer encoding
send-email: accept long lines with suitable transfer encoding
send-email: automatically determine transfer-encoding
Documen
no need to fail in this case. The auto transfer encoding handles this
specific case, so accept it as well.
Signed-off-by: brian m. carlson
---
Documentation/git-send-email.txt | 5 +++--
git-send-email.perl | 8 ++--
t/t9001-send-email.sh| 13 +
3 fi
sion of these two headers
will affect the deliverability of messages in anything but a positive
way, since MIME is already widespread and well understood by most email
programs.
Signed-off-by: brian m. carlson
---
Documentation/git-send-email.txt | 3 +--
git-send-email.perl | 18 ++
On Fri, Jul 06, 2018 at 08:26:04AM -0400, Drew DeVault wrote:
> On 2018-07-06 2:23 AM, brian m. carlson wrote:
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index a76953c310..4ea30c4070 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.p
On Fri, Jul 06, 2018 at 02:01:25AM -0400, Eric Sunshine wrote:
> On Thu, Jul 5, 2018 at 10:24 PM brian m. carlson
> wrote:
> > For most patches, using a transfer encoding of 8bit provides good
> > compatibility with most servers and makes it as easy as possible to view
>
l second
Should this affect the "# Merge the topic branch" line (and the "# C",
"# E", and "# H" lines in the next test) that appears below this? It
would seem those would qualify as comments as well.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
.
Add a transfer encoding value, auto, which indicates that a patch should
use 8bit where allowed and quoted-printable otherwise. Choose
quoted-printable instead of base64, since base64-encoded plain text is
treated as suspicious by some spam filters.
Signed-off-by: brian m. carlson
no need to fail in this case. The auto transfer encoding handles this
specific case, so accept it as well.
Signed-off-by: brian m. carlson
---
Documentation/git-send-email.txt | 7 +--
git-send-email.perl | 18 +++---
t/t9001-send-email.sh| 13 +++
instead of RFC 2821.
Signed-off-by: brian m. carlson
---
Documentation/git-send-email.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 2f32dbf16d..465a4ecbed 100644
--- a/Documentation/git-send-email.txt
sion of these two headers
will affect the deliverability of messages in anything but a positive
way, since MIME is already widespread and well understood by most email
programs.
Signed-off-by: brian m. carlson
---
Documentation/git-send-email.txt | 3 +--
git-send-email.perl | 18 ++
in an if block instead of returning early.
* Update documentation to reflect correct, modern RFC.
brian m. carlson (4):
send-email: add an auto option for transfer encoding
send-email: accept long lines with suitable transfer encoding
send-email: automatically determine transfer-encoding
doc
Signed-off-by: brian m. carlson
---
sha1-name.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/sha1-name.c b/sha1-name.c
index 60d9ef3c7e..ba6a5a689f 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -310,7 +310,7 @@ static int init_object_disambiguation(const char
: brian m. carlson
---
cache.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index d49092d94d..c4a64278a1 100644
--- a/cache.h
+++ b/cache.h
@@ -977,7 +977,7 @@ static inline int hashcmp(const unsigned char *sha1, const
unsigned char *sha2)
static
This is the fourteenth series of patches to switch to using struct
object_id and the_hash_algo. This series converts several core pieces
to use struct object_id, including the oid* and hex functions.
All of these patches have been tested with both SHA-1 and a 256-bit
hash.
brian m. carlson (17
Convert several uses of GIT_SHA1_HEXSZ into references to the_hash_algo.
Switch other uses into a use of parse_oid_hex and uses of its computed
pointer.
Signed-off-by: brian m. carlson
---
builtin/fmt-merge-msg.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff
Specify these constants in terms of the size of the hash algorithm
currently in use.
Signed-off-by: brian m. carlson
---
commit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index 0c3b75aeff..ff05d04570 100644
--- a/commit.c
+++ b/commit.c
Signed-off-by: brian m. carlson
---
diff.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 639eb646b9..485ff6c264 100644
--- a/diff.c
+++ b/diff.c
@@ -3832,7 +3832,7 @@ static const char *diff_abbrev_oid(const struct object_id
*oid, int abbrev
Switch from using get_oid_hex to parse_oid_hex to simplify pointer
operations and avoid the need for a hash-related constant.
Signed-off-by: brian m. carlson
---
builtin/update-index.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin/update-index.c b/builtin
Signed-off-by: brian m. carlson
---
log-tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/log-tree.c b/log-tree.c
index d3a43e29cd..9655de8ad7 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -545,7 +545,7 @@ void show_log(struct rev_info *opt)
struct strbuf msgbuf
Switch from using GIT_SHA1_HEXSZ to the_hash_algo to make the parsing of
the index information hash independent.
Signed-off-by: brian m. carlson
---
builtin/update-index.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update
In order to ensure we write the correct amount, use the_hash_algo to
find the correct number of bytes for the current hash.
Signed-off-by: brian m. carlson
---
refs/files-backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs/files-backend.c b/refs/files
In order to be sure we have enough space to use with any hash algorithm,
use GIT_MAX_HEXSZ to allocate space.
Signed-off-by: brian m. carlson
---
strbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/strbuf.c b/strbuf.c
index b0716ac585..030556111d 100644
--- a/strbuf.c
Use GIT_MAX_HEXSZ instead of GIT_SHA1_HEXSZ for an allocation so that it
is sufficiently large. Switch a comparison to use the_hash_algo to
determine the length of a hex object ID.
Signed-off-by: brian m. carlson
---
builtin/merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2
Convert one use of 20 and several uses of GIT_SHA1_HEXSZ into references
to the_hash_algo.
Signed-off-by: brian m. carlson
---
sha1-file.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sha1-file.c b/sha1-file.c
index de4839e634..1f66b9594f 100644
--- a/sha1-file.c
100 bytes is not sufficient to ensure we can write a commit message
buffer when using a 32-byte hash algorithm. Increase the buffer size to
ensure we have sufficient space.
Signed-off-by: brian m. carlson
---
refs/files-backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Switch several hard-coded constants into expressions based either on
GIT_MAX_HEXSZ or the_hash_algo.
Signed-off-by: brian m. carlson
---
pretty.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pretty.c b/pretty.c
index 703fa6ff7b..b0e653ff25 100644
--- a/pretty.c
+++ b
Switch uses of GIT_SHA1_HEXSZ to use the_hash_algo instead.
Signed-off-by: brian m. carlson
---
builtin/merge.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 4a4c09496c..916c9f0569 100644
--- a/builtin/merge.c
+++ b
Remove the hard-coded 20-based values and replace them with uses of
the_hash_algo.
Signed-off-by: brian m. carlson
---
tree-walk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tree-walk.c b/tree-walk.c
index 8f5090862b..c1f27086a9 100644
--- a/tree-walk.c
+++ b/tree
Instead of using the GIT_SHA1_* constants, switch to using the_hash_algo
to convert object IDs to and from hex format.
Signed-off-by: brian m. carlson
---
hex.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hex.c b/hex.c
index 8df2d63728..10af1a29e8 100644
--- a
On Sun, Jul 08, 2018 at 09:31:42PM -0700, Jacob Keller wrote:
> On Sun, Jul 8, 2018 at 9:05 PM Eric Sunshine wrote:
> >
> > On Sun, Jul 8, 2018 at 10:38 PM Jacob Keller wrote:
> > > On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
> > > wrote:
> > >
On Mon, Jul 09, 2018 at 10:45:33AM -0700, Junio C Hamano wrote:
> Derrick Stolee writes:
>
> > On 7/8/2018 7:36 PM, brian m. carlson wrote:
> >> diff --git a/refs/files-backend.c b/refs/files-backend.c
> >> index a9a066dcfb..252f835bae 100644
> >> --- a/ref
On Mon, Jul 09, 2018 at 09:48:55PM +0300, Daniel Harding wrote:
> Hello brian,
>
> On Mon, 09 Jul 2018 at 00:02:00 +0300, brian m. carlson wrote:
> > Should this affect the "# Merge the topic branch" line (and the "# C",
> > "# E", and "#
On Tue, Jul 10, 2018 at 02:08:28PM -0400, Ben Peart wrote:
>
>
> On 7/9/2018 7:39 PM, brian m. carlson wrote:
> > On Mon, Jul 09, 2018 at 10:45:33AM -0700, Junio C Hamano wrote:
> > > As Brandon alludes to downthread, we probably should use strbuf for
> > >
place it with strbuf(). Also
> update copy_reflog_msg() which is called only by log_ref_write_fd() to use
> strbuf as it keeps things consistent.
>
> Signed-off-by: Ben Peart
This looks good to me. Thanks for the patch.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://k
> caveats.
>
> Does it reproduce with older rebase (say from v2.10 days), too?
It appears to work correctly on the CentOS SCL Git 2.9.3. We print the
top level of the repository there.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
On Fri, Jul 13, 2018 at 04:19:49PM -0400, Jeff King wrote:
> Just reading over this thread, I suspect the simplest fix is to pass
> GIT_DIR and GIT_WORK_TREE together, which is almost always the right
> thing to do.
I agree. I'll write up a patch.
--
brian m. carlson: Houston, Tex
't correct: we respond with the subdirectory as
the top level, resulting in unexpected behavior.
Ensure that we pass GIT_WORK_TREE as well as GIT_DIR so that git
operations within subdirectories work correctly.
Signed-off-by: brian m. carlson
---
Dscho, is this test going to cause a problem
On Fri, Jul 13, 2018 at 08:57:03PM -0400, Jeff King wrote:
> On Sat, Jul 14, 2018 at 12:35:05AM +0000, brian m. carlson wrote:
>
> > diff --git a/sequencer.c b/sequencer.c
> > index 5354d4d51e..c8e16f9168 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> &
ere everybody told
> you the opposite. ;)
>
> So I guess my question/points are more for brian and Junio.
I'm okay with us forcing "openpgp". That seems sane enough for now, and
if people scream loudly, we can loosen it.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
f i can generate epoch->infinity
> to get the host clock or just the future out of the picture.
Yeah, I agree that would be good. If gpgsm does anything like what gpg
does, it will require the use of /dev/random, which means this will
definitely be slow on build servers and other noninteractive systems.
We have this problem at $DAYJOB when automating generation of gpg keys.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
t in adding support for other
tools, but I think this should make it easier if someone else wants to
do that.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
r functions are called only from revert, cherry-pick,
and rebase--helper; all of these commands require a working tree.
Signed-off-by: brian m. carlson
---
sequencer.c | 2 ++
t/t3404-rebase-interactive.sh | 9 +
2 files changed, 11 insertions(+)
diff --git a/sequencer.
n the
preferences of the administrator). However, it's easy enough for us to
simply build without RUNTIME_PREFIX if necessary.
If we turn it on by default, it would be nice if we documented (maybe in
the Makefile) that it requires /proc on Linux for the benefit of other
people who might be i
On Sat, Jul 14, 2018 at 11:05:34PM +0200, Johannes Schindelin wrote:
> Hi Brian,
>
> On Sat, 14 Jul 2018, brian m. carlson wrote:
> > Dscho, is this test going to cause a problem on Windows with the forward
> > slash in the grep statement?
>
> It passes on Windows.
Specify these constants in terms of the size of the hash algorithm
currently in use.
Signed-off-by: brian m. carlson
---
commit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index 0c3b75aeff..ff05d04570 100644
--- a/commit.c
+++ b/commit.c
Switch from using GIT_SHA1_HEXSZ to the_hash_algo to make the parsing of
the index information hash independent.
Signed-off-by: brian m. carlson
---
builtin/update-index.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update
Remove the hard-coded 20-based values and replace them with uses of
the_hash_algo.
Signed-off-by: brian m. carlson
---
tree-walk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tree-walk.c b/tree-walk.c
index 8f5090862b..c1f27086a9 100644
--- a/tree-walk.c
+++ b/tree
In order to ensure we write the correct amount, use the_hash_algo to
find the correct number of bytes for the current hash.
Signed-off-by: brian m. carlson
---
refs/files-backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs/files-backend.c b/refs/files
are fixes for things that will clearly cause
segfaults or other very obvious breakage on a Git with a 256-bit hash.
Changes from v1:
* Drop patch that's been replaced by one from Ben Peart.
* Update patch handling hash* and oid* functions.
tbdiff output below.
brian m. carlson (16):
Convert one use of 20 and several uses of GIT_SHA1_HEXSZ into references
to the_hash_algo.
Signed-off-by: brian m. carlson
---
sha1-file.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sha1-file.c b/sha1-file.c
index de4839e634..1f66b9594f 100644
--- a/sha1-file.c
Signed-off-by: brian m. carlson
---
diff.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 639eb646b9..485ff6c264 100644
--- a/diff.c
+++ b/diff.c
@@ -3832,7 +3832,7 @@ static const char *diff_abbrev_oid(const struct object_id
*oid, int abbrev
In order to be sure we have enough space to use with any hash algorithm,
use GIT_MAX_HEXSZ to allocate space.
Signed-off-by: brian m. carlson
---
strbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/strbuf.c b/strbuf.c
index b0716ac585..030556111d 100644
--- a/strbuf.c
Use GIT_MAX_HEXSZ instead of GIT_SHA1_HEXSZ for an allocation so that it
is sufficiently large. Switch a comparison to use the_hash_algo to
determine the length of a hex object ID.
Signed-off-by: brian m. carlson
---
builtin/merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2
Convert several uses of GIT_SHA1_HEXSZ into references to the_hash_algo.
Switch other uses into a use of parse_oid_hex and uses of its computed
pointer.
Signed-off-by: brian m. carlson
---
builtin/fmt-merge-msg.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff
has the effect of making the corresponding oid* functions use
the_hash_algo as well.
Signed-off-by: brian m. carlson
---
cache.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index d49092d94d..f00cc810bc 100644
--- a/cache.h
+++ b/cache.h
@@ -972,7
Switch several hard-coded constants into expressions based either on
GIT_MAX_HEXSZ or the_hash_algo.
Signed-off-by: brian m. carlson
---
pretty.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pretty.c b/pretty.c
index 703fa6ff7b..b0e653ff25 100644
--- a/pretty.c
+++ b
Signed-off-by: brian m. carlson
---
log-tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/log-tree.c b/log-tree.c
index d3a43e29cd..9655de8ad7 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -545,7 +545,7 @@ void show_log(struct rev_info *opt)
struct strbuf msgbuf
Switch uses of GIT_SHA1_HEXSZ to use the_hash_algo instead.
Signed-off-by: brian m. carlson
---
builtin/merge.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 4a4c09496c..916c9f0569 100644
--- a/builtin/merge.c
+++ b
Signed-off-by: brian m. carlson
---
sha1-name.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/sha1-name.c b/sha1-name.c
index 60d9ef3c7e..ba6a5a689f 100644
--- a/sha1-name.c
+++ b/sha1-name.c
@@ -310,7 +310,7 @@ static int init_object_disambiguation(const char
Instead of using the GIT_SHA1_* constants, switch to using the_hash_algo
to convert object IDs to and from hex format.
Signed-off-by: brian m. carlson
---
hex.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hex.c b/hex.c
index 8df2d63728..10af1a29e8 100644
--- a
Switch from using get_oid_hex to parse_oid_hex to simplify pointer
operations and avoid the need for a hash-related constant.
Signed-off-by: brian m. carlson
---
builtin/update-index.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin/update-index.c b/builtin
"sign.format", "signing.format",
or "signingtool.format" (I tend to prefer the former, but not too
strongly).
I anticipate that some projects will prefer other formats, and it makes
it easier if we don't have to maintain two sets of legacy names.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
On Wed, Jul 18, 2018 at 02:18:44PM +0200, Johannes Schindelin wrote:
> On Sat, 14 Jul 2018, brian m. carlson wrote:
> > I will say that at cPanel, we have a configuration where end users can
> > end up inside a mount namespace without /proc (depending on the
> > preferences
sounds like a good idea to me.
I'll reroll with that change and a commit message update. I think it's
important that we get this issue fixed for the release, and then we can
choose to implement a more comprehensive solution later.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
using freed memory. git
index-pack will read the repository's shallow file, which will have been
updated with the correct information.
Signed-off-by: brian m. carlson
---
fetch-pack.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fetch-pack.c b/fetch-pack.c
index 577faa6229..a9262
nstead.
That's fine with me. Sorry about the delay getting the reroll in.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
6 (with
a proper BOM) with musl and Git will have their data corrupted,
according to my reading of the musl website.
In other words, I believe this test is failing legitimately.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
e with the fact that the test (and
the corresponding functionality) won't work as expected with UTF-16,
then I agree that no action is needed.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
On Fri, Feb 08, 2019 at 12:55:11PM +0100, Kevin Daudt wrote:
> On Fri, Feb 08, 2019 at 11:45:02AM +0000, brian m. carlson wrote:
> > On Fri, Feb 08, 2019 at 01:04:03AM -0500, Rich Felker wrote:
> > [..]
> > > In any case, this test seems mainly relevant to Windows user
through, but test 3 then fails, because git itself output the file
> without BOM, presumably because it's passed through iconv.
>
> So I'm not sure if it's a matter of just fixing the tests.
I think something like the following will likely work in this scenario:
--
dn't think the
> command-line tool was. If it really is available everywhere, then yeah,
> I'd be fine with it.
It's not. POSIX doesn't specify the command, and macOS lacks it, I
believe.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
't matter to me one way or another, as
> long as I can get the dependency to /dev/zero removed so tests will run here.
My preference is that we wrap the yes/tr invocation into a function
(maybe "infinite_nul") and use that where we currently require
/dev/zero.
--
brian m. c
801 - 900 of 2732 matches
Mail list logo
