Johannes Schindelin writes:
> - the most important part will be the patch turning core.enableSHA1DC
> into a tristate: "externalOnly" or "smart" or "auto" or something
> indicating that it switches on collision detection only for commands
> that accept objects from an outside source into th
Johannes Schindelin writes:
> diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c
> index 6dd0da36084..d99db4f2e1b 100644
> --- a/sha1dc/sha1.c
> +++ b/sha1dc/sha1.c
> @@ -35,7 +35,7 @@
>
> #define sha1_mix(W, t) (rotate_left(W[t - 3] ^ W[t - 8] ^ W[t - 14] ^ W[t -
> 16], 1))
>
> -#if defined(BIGEN
On 2017-03-24 16:27, Ben Peart wrote:
> Add packet_writel() which writes multiple lines in a single call and
> then calls packet_flush_gently(). Add packet_read_line_gently() to
> enable reading a line without dying on EOF.
>
> Signed-off-by: Ben Peart
> ---
> pkt-line.c | 31 +++
Johannes Schindelin wrote:
> On Tue, 21 Mar 2017, Ivan Tham wrote:
> > Stefan Beller wrote:
> > > On Mon, Mar 20, 2017 at 9:41 AM, Ivan Tham wrote:
> > > > I am Ivan Tham. Currently studying in Computer Science in APIIT
> > > > Malaysia. I am interested particapate in Google Summer of Code 2017
Stefan Beller wrote:
> v7:
> * taken all of Jonathan minor nits, so patch 1..6 should be good to go
> * patch 7 lacks tests and documentation (according to Jonathan...)
> but as it is the last patch, just fixing a minor detail we can leave it off.
>
> Junio, please take patch 1-6 as usual, I wil
> On Fri, Mar 24, 2017 at 2:02 PM, Stefan Beller wrote:
> Welcome to the Git community!
Thank you!
> Please use a more imperative style. (e.g. s/Uses/Use/ ...
> s/and simplfying/which simplifies/)
Thank you. Will do in a second version of this patch.
> Thanks for this link. It gives good cont
When a nested submodule has untracked files, it would be reported as
"modified submodule" in the superproject, because submodules are not
parsed correctly in is_submodule_modified as they are bucketed into
the modified pile as "they are not an untracked file".
Signed-off-by: Stefan Beller
---
su
v7:
* taken all of Jonathan minor nits, so patch 1..6 should be good to go
* patch 7 lacks tests and documentation (according to Jonathan...)
but as it is the last patch, just fixing a minor detail we can leave it off.
Junio, please take patch 1-6 as usual, I will be out until next Wednesday.
Migrate 'is_submodule_modified' to the new porcelain format of
git-status. This conversion attempts to convert faithfully, i.e.
the behavior ought to be exactly the same.
As the output in the parsing only distinguishes between untracked files
and the rest, this is easy to port to the new format, a
This makes it easier for a follow up patch.
Signed-off-by: Stefan Beller
Reviewed-by: Jonathan Nieder
---
submodule.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/submodule.c b/submodule.c
index 2c667ac95a..93e3fefd39 100644
--- a/submodule.c
+++ b/submod
Instead of implementing line reading yet again, make use of our beautiful
library function to read one line. By using strbuf_getwholeline instead
of strbuf_read, we avoid having to allocate memory for the entire child
process output at once. That is, we limit maximum memory usage.
Also we can sta
struct argv_array is easier to use and maintain.
Signed-off-by: Stefan Beller
Reviewed-by: Jonathan Nieder
---
submodule.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/submodule.c b/submodule.c
index 3200b7bb2b..2c667ac95a 100644
--- a/submodule.c
+++ b/submodu
If I add an untracked file to a submodule or modify a tracked file,
currently "git status --short" treats the change in the same way as
changes to the current HEAD of the submodule:
$ git clone --quiet --recurse-submodules
https://gerrit.googlesource.com/gerrit
$ echo hello >gerri
By having a stricter check in the superproject we catch errors earlier,
instead of spawning a child process to tell us.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
submodule.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/submodule.c b/submodule.c
in
On Fri, Mar 24, 2017 at 4:31 PM, Jonathan Nieder wrote:
>
> Can this overflow the buffer? Submodule state is supposed to be 4
> characters, so could do
>
> /*
> * T XY :
> * T = line type, XY = status, = submodule
On Fri, Mar 24, 2017 at 3:38 PM, Jonathan Nieder wrote:
> It also overlaps work a little better.
mentioned
>> Once we know all information that we care about, we can terminate
>> the child early. In that case we do not care about its exit code as well.
>
> Should this say something about SIGPIPE
Hi Junio,
On Thu, 23 Mar 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > @@ -926,14 +930,14 @@ static void record_in_rewritten(struct object_id *oid,
> > static int do_pick_commit(enum todo_command command, struct commit *commit,
> > struct replay_opts *opts, int fi
On 03/24, Junio C Hamano wrote:
> * bw/recurse-submodules-relative-fix (2017-03-17) 5 commits
> - ls-files: fix bug when recursing with relative pathspec
> - ls-files: fix typo in variable name
> - grep: fix bug when recursing with relative pathspec
> - setup: allow for prefix to be passed to g
They're changing their license[1] to Apache 2 which unlike the current
fuzzy compatibility with the current license[2] is explicitly
incompatible with GPLv2[3].
We use OpenSSL for SHA1 by default unless NO_OPENSSL=YesPlease.
This still hasn't happened, but given the lifetime of git versions
packa
Hi Peff,
On Thu, 23 Mar 2017, Jeff King wrote:
> My pattern is particularly spiky from Travis's perspective, because once
> a day I rebase everything on top of master and push them the whole thing
> in a bunch. So they 75 branches, all at once. That seems like it would
> be ripe for throttling (t
Stefan Beller wrote:
> When a nested submodule has untracked files, it would be reported as
> "modified submodule" in the superproject, because submodules are not
> parsed correctly in is_submodule_modified as they are bucketed into
> the modified pile as "they are not an untracked file".
>
> Sig
Signed-off-by: Johannes Schindelin
---
config.mak.uname | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.uname b/config.mak.uname
index 399fe192719..a16e9ef0551 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -552,6 +552,7 @@ else
USE_LIBPCRE= YesPlease
To demonstrate the need for the core.enableSHA1DC knob, this test
compares the performance of the SHA-1 algorithms with collision
detection vs OpenSSL's (that does not detect attempted collision
attacks).
The payload size of 300MB was actually not concocted from thin air, but
is based on the massi
On Fri, Mar 24, 2017 at 10:21 PM, Junio C Hamano wrote:
> * ab/test-readme-updates (2017-03-23) 4 commits
> - SQUASH???
> - t/README: clarify the test_have_prereq documentation
> - t/README: change "Inside part" to "Inside the part"
> - t/README: link to metacpan.org, not search.cpan.org
>
Nowadays, there are practical collision attacks on the SHA-1 algorithm.
For that reason, Git integrated code that detects attempts to sneak in
objects using those known attack vectors and enabled it by default.
The collision detection is not for free, though: when using the SHA1DC
code, calculatin
In sha1dc/sha1.c, we #define BIGENDIAN under certain circumstances, and
obviously leave the door open for scenarios where our conditions do not
catch and that constant is #defined elsewhere.
However, we did not expect that anybody would possibly #define BIGENDIAN
to 0, indicating that the current
Signed-off-by: Johannes Schindelin
---
Makefile | 1 +
t/helper/test-sha1.c | 10 ++
t/t0013-sha1dc.sh| 10 ++
3 files changed, 21 insertions(+)
diff --git a/Makefile b/Makefile
index 3e181d2f0e2..0b581357625 100644
--- a/Makefile
+++ b/Makefile
@@ -2251,6 +2251,
When compiled with DC_AND_OPENSSL_SHA1, this new config setting allows to
switch from the collision-detecting SHA-1 routines (SHA1DC) to the
noticeably faster OpenSSL ones.
The default is still to detect collisions.
Signed-off-by: Johannes Schindelin
---
config.c | 8
1 file changed, 8
So far, there is only one test case in that script, and that case indeed
requires that the code was compiled with with the DC_SHA1 flag.
However, we are about to add another test case to verify that the
DC_AND_OPENSSL_SHA1 flag works correctly, too.
So let's refactor the code a little.
Signed-of
As I pointed out several times in the past, the performance hit of
enabling SHA1DC globally is not acceptable. This patch series not only
demonstrates that clearly in the perf test it adds (it is the last patch
in the current series, and its commit message has some numbers), it also
shows an early
Add a nascent WIP facility to specify via the options parsing that
we'd e.g. like to grab the --status option for commit.status from the
commit.status config key.
This is all very proof-of-concept, and uses the ugly hack of s/const
// for the options struct because I'm now keeping state in it, as
Stefan Beller wrote:
> +++ b/wt-status.c
> @@ -431,10 +431,19 @@ static void wt_status_collect_changed_cb(struct
> diff_queue_struct *q,
> }
> if (!d->worktree_status)
> d->worktree_status = p->status;
> - d->dirty_submodule = p->two->
Dennis Kaarsemaker writes:
> @@ -52,7 +52,7 @@ static int get_mode(const char *path, int *mode)
> #endif
> else if (path == file_from_standard_input)
> *mode = create_ce_mode(0666);
> - else if (lstat(path, &st))
> + else if (dereference ? stat(path, &st) : lstat(path
In sha1dc/sha1.c, we #define BIGENDIAN under certain circumstances, and
obviously leave the door open for scenarios where our conditions do not
catch and that constant is #defined elsewhere.
However, we did not expect that anybody would possibly #define BIGENDIAN
to 0, indicating that the current
Stefan Beller wrote:
> By having a stricter check in the superproject we catch errors earlier,
> instead of spawning a child process to tell us.
>
> Signed-off-by: Stefan Beller
> Reviewed-by: Jonathan Nieder
Yep. :)
Stefan Beller wrote:
[...]
> --- a/submodule.c
> +++ b/submodule.c
[...]
> @@ -1070,11 +1070,12 @@ unsigned is_submodule_modified(const char *path, int
> ignore_untracked)
[...]
> while (strbuf_getwholeline(&buf, fp, '\n') != EOF) {
> - if ((buf.buf[0] == '?') && (buf.buf[1] ==
Stefan Beller wrote:
> Instead of implementing line reading yet again, make use of our beautiful
> library function to read one line. By using strbuf_getwholeline instead
> of strbuf_read, we avoid having to allocate memory for the entire child
> process output at once. That is, we limit maximum
Stefan Beller wrote:
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1075,16 +1075,15 @@ unsigned is_submodule_modified(const char *path, int
> ignore_untracked)
> len = strbuf_read(&buf, cp.out, 1024);
> line = buf.buf;
> while (len > 2) {
> - if ((line[0] == '?') &&
Stefan Beller wrote:
> struct argv_array is easier to use and maintain
Missing '.' at end of sentence.
> Signed-off-by: Stefan Beller
> ---
> submodule.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
With or without that tweak, I still like this as much as last time. :)
R
Net::SMTP itself can do the necessary SSL and STARTTLS bits just fine
since version 1.28, and Net::SMTP::SSL is now deprecated. Since 1.28
isn't that old yet, keep the old code in place and use it when
necessary.
While we're in the area, mark some messages for translation that were
not yet marked
git diff <(command1) <(command2) is less useful than it could be, all it
outputs is:
diff --git a/dev/fd/63 b/dev/fd/62
index 9e6542b297..9f7b2c291b 12
--- a/dev/fd/63
+++ b/dev/fd/62
@@ -1 +1 @@
-pipe:[464811685]
\ No newline at end of file
+pipe:[464811687]
\ No newline at end of file
Norm
Git's diff machinery does not follow symlinks, which makes sense as git
itself also does not, but stores the symlink destination.
In --no-index mode however, it is useful for diff to be able to follow
symlinks, matching the behaviour of ordinary diff. A new --dereference
(name copied from diff) op
diff <(command1) <(command2) provides useful output, let's make it
possible for git to do the same.
Signed-off-by: Dennis Kaarsemaker
---
diff-no-index.c | 9 +
diff.c | 18 --
t/t4053-diff-no-index.sh | 10 ++
t/test-lib.sh
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The second maintenance release for
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
The latest maintenance release Git v2.12.2 is now available at the
usual places. These fixes have all been in the 'master' branch to
be included in the next feature release.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a
On Fri, Mar 24, 2017 at 12:10:49PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Actually this is a bit confusing, but I think reversing the arguments
> makes sense, i.e.:
>
> git branch -c dest [src]
>
> And similarly:
>
> git checkout -c dest []
>
> This is confusing in that it reverses th
On Thu, Mar 23, 2017 at 11:28:52AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > This series is the updated version of 'sg/completion-refs-speedup'.
> > It speeds up refs completion for large number of refs, partly by
> > giving up disambiguating ambiguous refs and partly by eliminat
On Thu, Mar 23, 2017 at 04:29:21PM +0100, SZEDER Gábor wrote:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 394dcece6..d26312899 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -42
On Thu, Mar 23, 2017 at 04:29:18PM +0100, SZEDER Gábor wrote:
> When completing refs, several __git_refs() code paths list all the
> refs from the refs/{heads,tags,remotes}/ hierarchy and then
> __gitcomp_nl() iterates over those refs in a shell loop to filter out
> refs not matching the current r
On Thu, Mar 23, 2017 at 04:29:17PM +0100, SZEDER Gábor wrote:
> However, it's questionable whether ambiguous refs are really that bad
> to justify that much extra cost:
It's not clear to me that the existing completion actually does a good
job with disambiguation anyway.
If I have a tag and a br
Jeff King writes:
> My one question would be whether people would want this to actually be
> specific to a particular remote, and not just on for a given repository
> (your "site-specific" in the description made me think of that). In that
> case it would be better as part of the remote.* config.
Jeff King writes:
> I see you ended up with a test that uses test_terminal, which is much
> better (and your patch looks good to me).
>
> But I was concerned that there might be a bug in pager_in_use(), so I
> dug into it a little. I think the code there is correct; it's just
> relaying the envir
On Fri, Mar 24, 2017 at 11:53:54AM -0700, Jonathan Nieder wrote:
> I didn't receive the original patch (maybe mailing delay?) so
> commenting here.
Vger seems a bit slow lately. The list copy did eventually get delivered
to me and public-inbox:
http://public-inbox.org/git/1490375874.745.227.ca
On Fri, Mar 24, 2017 at 02:55:43PM -0400, Jeff King wrote:
> But I was concerned that there might be a bug in pager_in_use(), so I
> dug into it a little. I think the code there is correct; [...]
I did see this small cleanup opportunity, though.
-- >8 --
Subject: [PATCH] pager_in_use: use git_en
On Thu, Mar 23, 2017 at 10:52:34AM -0600, Alex Henrie wrote:
> Unfortunately, I think I found a bug. Even when using `git -p`, the
> function pager_in_use() always returns false if the output is not a
> TTY. So, `isatty(1) || pager_in_use()` and `color_stdout_is_tty ||
> (pager_in_use() && pager_u
Hi,
Jeff King wrote:
> On Fri, Mar 24, 2017 at 06:17:54PM +0100, Romuald Brunet wrote:
>> Added a "push.atomic" option to git-config to allow site-specific
>> configuration of the atomic flag of git push
>
> I don't really use --atomic myself, but this seems like a reasonable
> thing to want, and
Dear Friend,
I need your help transferring (US$4.5M DOLLARS) to your bank account.I have
every enquiries’details to make the bank believed you and release the fund in
within 5 banking working days with your full co-operation with me for success.
Send the below requirement to enable me advice
On Fri, Mar 24, 2017 at 06:17:54PM +0100, Romuald Brunet wrote:
> Added a "push.atomic" option to git-config to allow site-specific
> configuration of the atomic flag of git push
I don't really use --atomic myself, but this seems like a reasonable
thing to want, and the implementation looks clean
Change the --points-at option to default to HEAD for consistency with
its siblings --contains, --merged etc. which default to
HEAD. Previously we'd get:
$ git tag --points-at 2>&1 | head -n 1
error: option `points-at' requires a value
This changes behavior added in commit ae7706b9ac (tag:
Reflow the recently changed branch/tag-for-each-ref
documentation. This change shows no changes under --word-diff, except
the innocuous change of moving git-tag.txt's "[--sort=]" around
slightly.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/git-branch.txt | 15 ---
Docume
Change the test suite to test for these synonyms for --contains and
--no-contains, respectively.
Before this change there were no tests for them at all. This doesn't
exhaustively test for them as well as their --contains and
--no-contains synonyms, but at least it's something.
Signed-off-by: Ævar
Change "suceed" to "succeed" in a test description. The typo has been
here since the code was originally added in commit ef5a6fb597 ("Add
test-script for git-tag", 2007-06-28).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t7004-tag.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Change the tag, branch & for-each-ref commands to have a --no-contains
option in addition to their longstanding --contains options.
This allows for finding the last-good rollout tag given a known-bad
. Given a hypothetically bad commit cf5c7253e0, the git
version to revert to can be found with thi
Change the "tag" command to implicitly turn on its --list mode when
provided with a list-like option such as --contains, --points-at etc.
This is for consistency with how "branch" works. When "branch" is
given a list-like option, such as --contains, it implicitly provides
--list. Before this chang
Change the documentation for --list so that it's described as a
toggle, not as an option that takes a as an argument.
Junio initially documented this in b867c7c23a ("git-tag: -l to list
tags (usability).", 2006-02-17), but later Jeff King changed "tag" to
accept multiple patterns in 588d0e834b ("
Change the tag test suite to test for --contains on a tree & blob. It
only accepts commits and will spew out " is a tree, not a
commit".
It's sufficient to test this just for the "tag" and "branch" commands,
because it covers all the machinery shared between "branch" and
"for-each-ref".
Signed-of
Change the behavior of specifying --merged & --no-merged to be an
error, instead of silently picking the option that was provided last.
Subsequent changes of mine add a --no-contains option in addition to
the existing --contains. Providing both of those isn't an error, and
has actual meaning.
Mak
Split up the --[no-]merged documentation into documentation that
documents each option independently. This is in line with how "branch"
and "for-each-ref" are documented, and makes subsequent changes to
discuss the limits & caveats of each option easier to read.
Signed-off-by: Ævar Arnfjörð Bjarma
Amend the test suite to test for more invalid uses like "-l -a"
etc.
This change tests the code path in builtin/tag.c between lines:
if (argc == 0 && !cmdmode)
And:
if ((create_tag_object || force) && (cmdmode != 0))
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t7004-tag.sh | 16
Change mentions of to in the help output of
for-each-ref as appropriate.
Both --[no-]merged and --contains only take commits, but --points-at
can take any object, such as a tag pointing to a tree or blob.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/for-each-ref.c | 4 ++--
1 file chang
Change the test for "git tag -l" to not have an associated TODO
comment saying that it should return non-zero if there's no tags.
This was added in commit ef5a6fb597 ("Add test-script for git-tag",
2007-06-28) when the tests for "tag" were initially added, but at this
point changing this would be
Add the OPT_NONEG flag to the "contains" option and its hidden synonym
"with". Since this was added in commit 694a577519 ("git-branch
--contains=commit", 2007-11-07) giving --no-{contains,with} hasn't
been an error, but has emitted the help output since
filter.with_commit wouldn't get set.
Now git
Change the wording for the --merged and --no-merged options to talk
about "commits" instead of "tips".
This phrasing was copied from the "branch" documentation in commit
5242860f54 ("tag.c: implement '--merged' and '--no-merged' options",
2015-09-10). Talking about the "tip" is branch nomenclature
Move the documentation for the --merged & --no-merged options earlier
in the documentation, to sit along the other switches, and right next
to the similar --contains and --points-at switches.
It makes more sense to group the options together, not have some
options after the like of , , etc.
This
Hopefully the final version. This is exactly like v3 except for a
couple of minor changes (and rebased on the latest upstream master):
Ævar Arnfjörð Bjarmason (16):
tag doc: move the description of --[no-]merged earlier
tag doc: split up the --[no-]merged documentation
tag doc: reword --[no
Alex Henrie wrote:
> Signed-off-by: Alex Henrie
> ---
> builtin/log.c | 9 -
> t/t4202-log.sh | 10 +-
> 2 files changed, 17 insertions(+), 2 deletions(-)
Nice.
Reviewed-by: Jonathan Nieder
By having a stricter check in the superproject we catch errors earlier,
instead of spawning a child process to tell us.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
submodule.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/submodule.c b/submodule.c
in
When a nested submodule has untracked files, it would be reported as
"modified submodule" in the superproject, because submodules are not
parsed correctly in is_submodule_modified as they are bucketed into
the modified pile as "they are not an untracked file".
Signed-off-by: Stefan Beller
---
su
Instead of implementing line reading yet again, make use of our beautiful
library function to read one line. By using strbuf_getwholeline instead
of strbuf_read, we avoid having to allocate memory for the entire child
process output at once. That is, we limit maximum memory usage.
Once we know al
Migrate 'is_submodule_modified' to the new porcelain format of
git-status. This conversion attempts to convert faithfully, i.e.
the behavior ought to be exactly the same.
As the output in the parsing only distinguishes between untracked files
and the rest, this is easy to port to the new format, a
If I add an untracked file to a submodule or modify a tracked file,
currently "git status --short" treats the change in the same way as
changes to the current HEAD of the submodule:
$ git clone --quiet --recurse-submodules
https://gerrit.googlesource.com/gerrit
$ echo hello >gerri
This makes it easier for a follow up patch.
Signed-off-by: Stefan Beller
---
submodule.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/submodule.c b/submodule.c
index 2c667ac95a..e52cb8a958 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1075,16 +1075,15 @@ u
v6:
* kill the child once we know all information that we ask for, as an
optimization
* reordered the patches for that
* strbuf_getwholeline instead of its _fd version.
v5:
* fixed rebase error in the first 2 patches
* the last 3 patches introduce behavior change outside the scope of
is_modified
struct argv_array is easier to use and maintain
Signed-off-by: Stefan Beller
---
submodule.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/submodule.c b/submodule.c
index 3200b7bb2b..2c667ac95a 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1043,12 +1043,6 @@ uns
On Fri, Mar 24, 2017 at 11:04:27AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It seems like t7030 should just skip_all when the GPG prereq is not
> > met (it's not wrong to mark each test that's added, but it would have
> > made this particular mistake harder).
>
> I'd leave that to
On Fri, Mar 24, 2017 at 12:49:43PM -0400, Jeff King wrote:
> On Fri, Mar 24, 2017 at 09:45:30AM -0700, Junio C Hamano wrote:
>
> > I actually think this uncovers another class of breakage. t7030
> > tests should be protected with GPG prereq and 'fourth-signed' that
> > is made only with the prer
Jeff King writes:
> It seems like t7030 should just skip_all when the GPG prereq is not
> met (it's not wrong to mark each test that's added, but it would have
> made this particular mistake harder).
I'd leave that to be done by others after the dust settles ;-).
Here is what I have right now
Ævar Arnfjörð Bjarmason writes:
> On Mon, Mar 20, 2017 at 11:05 PM, Junio C Hamano wrote:
>> But more importantly, aren't we essentially adding an equivalent of
>>
>> cd Documentation && cat git-*.txt
>>
>> to our codebase?
>>
>> Surely we cannot avoid having a copy of all messages that
Jeff Hostetler wrote:
> On 3/24/2017 12:35 PM, Jonathan Nieder wrote:
>> What happens if there is an error before the code reaches the end of
>> the function? I think there needs to be a verify_hdr_finish call in
>> the 'unmap:' cleanup section.
>
> But the "unmap" section calls die(). Do need t
Jeff Hostetler writes:
> WRT the assert() in name-hash.c, Stefan suggested converting it
> to an if-!-die form in an earlier message in this thread. I'm OK
> with that or with removing the assert completely.
I actually am OK with leaving things as they are ;-)
On 24/03/17 17:26, Ramsay Jones wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Jeff,
>
> If you need to re-roll your 'jh/memihash-opt' branch, could you please
> squash this into the relevant patch (commit f25dde4fbf, "name-hash: add
> test-lazy-init-name-hash", 23-03-2017).
>
> Thanks!
Alex Henrie writes:
> +test_expect_success TTY 'log output on a TTY' '
> + git log --oneline --decorate >expect.short &&
> +
> + test_terminal git log --oneline >actual &&
> + test_cmp expect.short actual
> +'
> +
Nice. I didn't know test_terminal was so easy to use ;-)
Looks good.
On 3/24/2017 12:35 PM, Jonathan Nieder wrote:
g...@jeffhostetler.com wrote:
From: Jeff Hostetler
Teash do_read_index() in read-cache.c to call verify_hdr()
...
Nice. Do you have example commands I can run to reproduce
that benchmark? (Even better if you can phrase that as a
patch against
The stream_blob() function checks the return value of
snprintf and dies. This is more simply done with
xsnprintf (and matches the similar call in store_object).
The message the user would get is less specific, but since
the point is that this _shouldn't_ ever happen, that's OK.
Signed-off-by: Jef
Several callers use fixed buffers for storing the pack
object header, and they've picked 10 as a magic number. This
is reasonable, since it handles objects up to 2^67. But
let's give them a constant so it's clear that the number
isn't pulled out of thin air.
Signed-off-by: Jeff King
---
builtin/
Signed-off-by: Ramsay Jones
---
Hi Jeff,
If you need to re-roll your 'jh/memihash-opt' branch, could you please
squash this into the relevant patch (commit f25dde4fbf, "name-hash: add
test-lazy-init-name-hash", 23-03-2017).
Thanks!
ATB,
Ramsay Jones
t/helper/.gitignore | 1 +
1 file changed
The encode_in_pack_object_header() writes a variable-length
header to an output buffer, but it doesn't actually know
long the buffer is. At first glance, this looks like it
might be possible to overflow.
In practice, this is probably impossible. The smallest
buffer we use is 10 bytes, which would
When we have to write a sha1 with a newline, we do so by
copying both into a single buffer, so that we can issue a
single write() call.
We use snprintf but don't bother to check the output, since
we know it will fit. However, we should use xsnprintf() in
such a case so that we're notified if our a
I don't think any of these is a triggerable bug. They're just cleanups
to make it more obvious that the code is doing the right thing (and
making it harder to do the wrong thing).
[1/4]: fast-import: use xsnprintf for writing sha1s
[2/4]: fast-import: use xsnprintf for formatting headers
[3/
1 - 100 of 149 matches
Mail list logo
