On Fri, Sep 07, 2018 at 07:22:05PM -0400, Todd Zullinger wrote:
> With curl-7.61.1 cookies are sorted by creation-time¹. Sort the output
> used in the 'cookies stored in http.cookiefile when http.savecookies
> set' test before comparing it to the expected cookies.
>
> ¹
to catch the most important cases.
Signed-off-by: Jeff King
---
config.mak.dev | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.dev b/config.mak.dev
index 9a998149d9..f832752454 100644
--- a/config.mak.dev
+++ b/config.mak.dev
@@ -14,6 +14,7 @@ CFLAGS += -Wpointer-arith
CFLAGS
On Fri, Sep 07, 2018 at 05:23:31PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Hrm, no. I spoke too soon because I was conflating "commit-graph write"
> v.s. "gc". For "gc" we're now with this change just e.g. spending 6
> seconds on 2015-04-03-1M-git displaying nothing, because we're looping
>
On Fri, Sep 07, 2018 at 11:52:58AM +0200, Allan Sandfeld Jensen wrote:
> Submodules checked out with older versions of git not longer works in the
> latest 2.19 releases. A "git submodule update --recursive" command wil fail
> for each submodule with a line saying "fatal: could not open
>
On Thu, Sep 06, 2018 at 11:32:41PM -0700, Jonathan Nieder wrote:
> > I think Stefan pointed out a "case 4" in the other part of the thread:
> > ones where we really care not just about fast lookup, but actual
> > iteration order.
>
> I had assumed that that was the whole point of this data
On Fri, Sep 07, 2018 at 06:27:40AM +0300, Max Kirillov wrote:
> On Thu, Sep 06, 2018 at 02:54:18PM -0700, Junio C Hamano wrote:
> > Max Kirillov writes:
> >> This should fix it. I'm not sure should it treat it as 0 or "-1"
> >> At least the tests mentioned by Jeff fails if I try to treat missing
On Mon, Sep 03, 2018 at 06:48:54PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > And there are definitely a few nasty bits (like the way the progress is
> > ended). I'm not planning on taking this further for now, but maybe
> > you or somebody can find it interesting or useful.
>
> I think it would
On Thu, Sep 06, 2018 at 04:50:33PM -0700, Jonathan Nieder wrote:
> Hi,
>
> Jeff King wrote:
>
> > But what I think is harmful is a _sorted_ list, because of the
> > "accidentally quadratic" nature, and because it's easy to call its
> > functions on an un
On Thu, Sep 06, 2018 at 01:54:15PM -0700, Stefan Beller wrote:
> > > It turns out we make never use of a custom compare function in
> > > the stringlist, which helps gaining confidence this use case is nowhere
> > > to be found in the code.
> >
> > Plenty of code uses the default strcmp. You can
On Thu, Sep 06, 2018 at 03:16:21PM -0700, Stefan Beller wrote:
> > It seems funny that we'd iterate through the list checking over and over
> > whether tracing is enabled.
> >
> > Should this do:
> >
> > if (!trace_want(_default_key))
> > return;
> >
> > at the top? (Or possibly even
On Thu, Sep 06, 2018 at 01:04:18PM -0700, Stefan Beller wrote:
> On Thu, Sep 6, 2018 at 12:12 PM Jeff King wrote:
> >
> > On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
> >
> > > > + string_list_append(_list, *argv[0]);
> > >
>
On Thu, Sep 06, 2018 at 11:58:16AM +0200, Christian Couder wrote:
> On Thu, Sep 6, 2018 at 3:14 AM, Jeff King wrote:
> > On Wed, Sep 05, 2018 at 09:20:23AM +0200, Christian Couder wrote:
> >
> >> >> Thanks. I think sooner is better for this (for you or anybody
On Thu, Sep 06, 2018 at 11:51:49AM +0200, Christian Couder wrote:
> > Thanks. I signed us up as a community (making me the "coordinator" in
> > their terminology). I think the procedure is a little different this
> > year, and we actually propose projects to mentor through their system.
>
>
On Thu, Sep 06, 2018 at 03:12:03PM -0400, Jeff King wrote:
> On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
>
> > > + string_list_append(_list, *argv[0]);
> >
> > This will create an unsorted list. You'd have to use
> > string_lis
On Thu, Sep 06, 2018 at 09:05:50PM +0200, Tim Schumacher wrote:
> On 06.09.18 16:57, Jeff King wrote:
> > On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >
> > > If we don't have some test for these sort of aliasing loops that fails
> &g
On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
> > + string_list_append(_list, *argv[0]);
>
> This will create an unsorted list. You'd have to use
> string_list_insert() here for a sorted list, or
> unsorted_string_list_has_string() in the earli
On Thu, Sep 06, 2018 at 11:40:14AM -0700, Junio C Hamano wrote:
> Also, normal users who have never seen this loop that implements
> alias expansion would not have a clue when they see "called twice".
>
> I actually think the caller should also pass cmd to run_argv() and
> then we should use it
On Thu, Sep 06, 2018 at 09:52:28AM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > It is a debugging aid, so it should print to the debugging channel.
>
> ... and rename it with trace_ prefix.
>
> Use of trace_printf() is nice, as we can control its behavior at
> runtime ;-)
Yes,
On Thu, Sep 06, 2018 at 05:10:04PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > seen = unsorted_string_list_lookup(_list, *argv[0]);
> > if (seen) {
> > for (i = 0; i < cmd_list.nr; i++) {
> > struct string_list *item = cmd_list.items[i];
> >
> > strbuf_addf(, "
On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:
> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)
> /* .. then try the external ones */
> execv_dashed_external(*argv);
>
> - /* It could be an alias -- this works
On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
> If we don't have some test for these sort of aliasing loops that fails
> now, we really should add that in a 1/2 and fix it in this patch in 2/2.
Yes, I'd agree that this is worth adding a test (especially if the
output
On Mon, Sep 03, 2018 at 06:36:19AM +0200, Christian Couder wrote:
> So here is a landing page for the next Outreachy round:
>
> https://git.github.io/Outreachy-17/
>
> about the microprojects I am not sure which page I should create or improve.
Thanks. I signed us up as a community (making me
On Wed, Sep 05, 2018 at 09:20:23AM +0200, Christian Couder wrote:
> >> Thanks. I think sooner is better for this (for you or anybody else who's
> >> interested in mentoring). The application period opens on September
> >> 10th, but I think the (still growing) list of projects is already being
>
On Wed, Sep 05, 2018 at 05:50:04AM -0400, Eric Sunshine wrote:
> On Tue, Sep 4, 2018 at 6:36 PM Junio C Hamano wrote:
> > * es/worktree-forced-ops-fix (2018-08-30) 9 commits
> > - worktree: delete .git/worktrees if empty after 'remove'
> > - worktree: teach 'remove' to override lock when
On Wed, Sep 05, 2018 at 02:38:34PM -0400, Eric Sunshine wrote:
> On Wed, Sep 5, 2018 at 8:39 AM Johannes Schindelin
> wrote:
> > So let's hear some ideas how to improve the situation, m'kay?
> > Just as a reminder, this is the problem I want to solve: I want to run the
> > tests in a
On Wed, Sep 05, 2018 at 10:54:27AM +0200, Tim Schumacher wrote:
> Aliases can only contain non-alias git commands and their
> arguments, not other user-defined aliases. Resolving further
> (nested) aliases is prevented by breaking the loop after the
> first alias was processed. Git then fails
On Wed, Sep 05, 2018 at 09:54:42AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> > So AFAIK this fsck catches everything and yields a non-zero exit in the
> >> > error case. And it should work for even a single byte of rubbish.
> >>
> >&g
On Wed, Sep 05, 2018 at 05:39:19PM +0200, Duy Nguyen wrote:
> On Wed, Sep 5, 2018 at 5:35 PM Jeff King wrote:
> > > > + after=$(wc -c <.git/index) &&
> > > > +
> > > > + # double check that the in
On Wed, Sep 05, 2018 at 05:27:11PM +0200, Duy Nguyen wrote:
> > +test_expect_success PERL 'commit -p with shrinking cache-tree' '
> > + mkdir -p deep/subdir &&
> > + echo content >deep/subdir/file &&
> > + git add deep &&
> > + git commit -m add &&
> > + git rm -r
On Tue, Sep 04, 2018 at 12:38:07PM -0400, Jeff King wrote:
> > And just to be clear I'm looking forward to a patch from Jeff to fix
> > this since he clearly put more thoughts on this than me. With commit.c
> > being the only user of reopen_lock_file() I guess it's even ok
On Tue, Sep 04, 2018 at 10:55:35AM -0700, Junio C Hamano wrote:
> Tim Schumacher writes:
>
> > I submitted this as RFC because I'm not sure whether disallowing
> > nested aliases was an intentional design choice. The done_alias
> > check implies that disallowing is intended, but the direct
> >
On Tue, Sep 04, 2018 at 12:30:14PM -0700, Stefan Beller wrote:
> > [1/4]: bitmap_has_sha1_in_uninteresting(): drop BUG check
> >
> > The actual fix. This should get merged to next ASAP (or the original
> > topic just reverted).
> >
> > [2/4]: t5310: test delta reuse with bitmaps
> >
>
On Tue, Sep 04, 2018 at 12:05:58PM -0700, Stefan Beller wrote:
> Yeah, maybe we need to ask for more tests in the 'real' test suite, and not
> just in some special corner (such as t/perf/ or any of the environment
> variable proposals nearby).
>
> I wonder if we can make use of git.git in the
On Tue, Sep 04, 2018 at 06:13:36PM +0200, Duy Nguyen wrote:
> > > Doh, of course. I even thought about this issue and dug all the way into
> > > reopen_lock_file(), but for some reason temporarily forgot that O_WRONLY
> > > does not imply O_TRUNC.
> > >
> > > Arguably this should be the default
On Sun, Sep 02, 2018 at 03:55:28AM -0400, Jeff King wrote:
> I still think the more interesting long-term thing here is to reuse the
> pack verification from index-pack, which actually hashes as it does the
> per-object countup.
>
> That code isn't lib-ified enough to be run in
On Sun, Sep 02, 2018 at 09:37:59AM +0200, Christian Couder wrote:
> > I also think it doesn't need to be the mentor's responsibility to find
> > the funding. That can be up to an "org admin", and I don't think it
> > should be too big a deal (I had no trouble getting funding from GitHub
> > last
On Sun, Sep 02, 2018 at 09:53:53AM +0200, Luc Van Oostenryck wrote:
> > At any rate, I think this perfectly explains the behavior we're seeing.
>
> Yes, this certainly make sense.
>
> For fun (and testing) I tried to take the problem in the other direction:
> * why hasn't this be detected
On Sun, Sep 02, 2018 at 03:46:57AM -0400, Jeff King wrote:
> Something like this, which chunks it there, uses a per-packfile meter
> (though still does not give any clue how many packfiles there are), and
> shows a throughput meter.
Actually, in typical cases it would not matter
On Sat, Sep 01, 2018 at 02:53:28PM +0200, Ævar Arnfjörð Bjarmason wrote:
> With this we'll get output like:
>
> $ ~/g/git/git -C ~/g/2015-04-03-1M-git/ --exec-path=$PWD fsck
> Checking object directories: 100% (256/256), done.
> Hashing: 100% (452634108/452634108), done.
>
On Sun, Sep 02, 2018 at 09:12:04AM +0200, Duy Nguyen wrote:
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index 0d9828e29e..779c5e2cb5 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -359,13 +359,6 @@ static const char *prepare_index(int argc, const char
> >
On Sat, Sep 01, 2018 at 10:29:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Anyway. Not that exciting, and kind of obviously dumb in retrospect. But
> > I think it was worth analyzing to see what went wrong. If there's an
> > immediate lesson, it is probably: add tests even for changes that
On Sun, Sep 02, 2018 at 12:17:53AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Here are the steps to reproduce it:
> > $ git clone git://github.com/lucvoo/sparse-dev.git
> > $ cd
> > $ git co index-corruption
> > $ git rm -r validation/ Documentation/
> > $ git commit -m -p
> > $ git
On Fri, Aug 31, 2018 at 10:16:49AM +0200, Christian Couder wrote:
> > 2. To get our landing page and list of projects in order (and also
> > micro-projects for applicants). This can probably build on the
> > previous round at:
> >
> >https://git.github.io/Outreachy-15/
> >
> >
On Fri, Aug 31, 2018 at 01:30:05PM +0300, Оля Тележная wrote:
> I was Outreachy intern last winter. I guess I need to speak up: I will
> be happy if my feedback helps you.
> At first, I want to repeat all thanks to Outreachy organizers and Git
> mentors. That was unique experience and I am so
On Sat, Sep 01, 2018 at 03:48:13AM -0400, Jeff King wrote:
> Commit 6a1e32d532 (pack-objects: reuse on-disk deltas for
> thin "have" objects, 2018-08-21) taught pack-objects a new
> optimization trick. Since this wasn't meant to change
> user-visible behavior, but only prod
the loaded flag is not true. Nor is
it possible to accidentally pass an already-loaded
bitmap_index to the loading function (which is static-local
to the file).
We can drop this unnecessary and confusing flag.
Signed-off-by: Jeff King
---
pack-bitmap.c | 9 +++--
1 file changed, 3 insertions
ng packed_git struct, so that multiple
prepare_bitmap_walk() calls could use it. That can wait
until somebody actually has need of the optimization (and
until then, we'll do the correct, unsurprising thing).
Signed-off-by: Jeff King
---
pack-bitmap.c | 3 ---
1 file changed, 3 deletions(-
nce people don't run perf tests very often, we
should make sure that the feature is exercised in the
regular test suite. This patch does so.
Signed-off-by: Jeff King
---
Side note: If we do squash patch 1 into the eariler series, that will
invalidate the commit id mentioned in the commit message here.
e too-small
example repositories. But any reasonably-sized real-world
push or fetch (with bitmaps) would trigger this.
This patch drops the harmful assertion and tweaks the
docstring for the function to make the precondition clear.
The tests need to be improved to exercise this new
pack-objects featur
On Fri, Aug 31, 2018 at 06:55:58PM -0400, Jeff King wrote:
> On Fri, Aug 31, 2018 at 05:23:17PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > On Tue, Aug 21 2018, Jeff King wrote:
> >
> > > +int bitmap_has_sha1_in_uninteresting(stru
On Fri, Aug 31, 2018 at 05:23:17PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Aug 21 2018, Jeff King wrote:
>
> > +int bitmap_has_sha1_in_uninteresting(struct bitmap_index *bitmap_git,
> > +const unsigned char *sha1)
>
On Fri, Aug 31, 2018 at 11:14:20PM +0200, Johannes Schindelin wrote:
> On Fri, 31 Aug 2018, Junio C Hamano wrote:
> [...]
> > So instead of typing 3 lines, you can just say "yes we use echo that
> > emulates Unix".
>
> You could just express your gratitude that I do more than just answer a
>
On Fri, Aug 31, 2018 at 10:38:44PM +0200, Johannes Schindelin wrote:
> > > Is there any reason why you avoid using `git rebase -ir` here? This should
> > > be so much easier via
> > >
> > > git checkout pk/rebase-i-in-c-6-final
> > > git rebase -ir js/rebase-in-c-5.5-work-with-rebase-i-in-c^
On Fri, Aug 31, 2018 at 02:33:15AM -0400, Eric Sunshine wrote:
> This series replaces Peff's solo patch[1] which updates "make clean" to
> remove doc-diff's temporary directory. Rather than imbuing the Makefile
> with knowledge specific to doc-diff's internals, this series adds a
> "clean" mode
On Fri, Aug 31, 2018 at 02:33:18AM -0400, Eric Sunshine wrote:
> doc-diff creates a temporary working tree (git-worktree) and generates a
> bunch of temporary files which it does not remove since they act as a
> cache to speed up subsequent runs. Although doc-diff's working tree and
> generated
On Fri, Aug 31, 2018 at 02:33:17AM -0400, Eric Sunshine wrote:
> As part of its operation, doc-diff creates a bunch of temporary
> working files and holds onto them in order to speed up subsequent
> invocations. These files are never deleted. Moreover, it creates a
> temporary working tree (via
On Fri, Aug 31, 2018 at 02:33:16AM -0400, Eric Sunshine wrote:
> doc-diff invokes 'man' with the -l option to force "local" mode,
> however, neither MacOS nor FreeBSD recognize this option. On those
> platforms, if the argument to 'man' contains a slash, it is
> automatically interpreted as a
On Fri, Aug 31, 2018 at 08:33:26AM -0700, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> Would "echo base >base" give us 5-byte long base even on Windows?
> >
> > Please note that Unix shell scripting is a foreign thing on Windows. As
> > such, there is not really any "native" shell
On Fri, Aug 31, 2018 at 12:49:39AM +0100, Ramsay Jones wrote:
> On 30/08/18 21:14, Junio C Hamano wrote:
> > Jeff King writes:
> >
> >> I suppose so. I don't think I've _ever_ used distclean, and I only
> >> rarely use "clean" (a testament to our
On Thu, Aug 30, 2018 at 04:34:43PM -0400, Eric Sunshine wrote:
> On Thu, Aug 30, 2018 at 3:55 PM Jeff King wrote:
> > The tmp-doc-diff directory isn't strictly a build product of
> > the Makefile, since it's only present if you manually run
> > the doc-diff script. But
On Thu, Aug 30, 2018 at 01:29:53PM -0700, Junio C Hamano wrote:
> >> > I do not know if the documentation that is shipped in 2.20 should
> >> > talk about how the old world looked like, though. `-l` was a short
> >> > for `--create-reflog` is worth saying, but I do not see much value
> >> > in
On Thu, Aug 30, 2018 at 01:03:41PM +0200, Johannes Schindelin wrote:
> > Will replace by doing:
> >
> > $ git checkout js/rebase-in-c-5.5-work-with-rebase-i-in-c
> > $ git checkout HEAD^
> > $ git am -s mbox
> > $ git range-diff @{-1}...
> > $ git checkout -B @{-1}
> >
> >
remove obsolete "-l" references
The previous commit switched "-l" to meaning "--list", but a
few vestiges of its prior meaning as "--create-reflog"
remained:
- the synopsis mentioned "-l" when creating a new branch;
we can drop this entirely,
The tmp-doc-diff directory isn't strictly a build product of
the Makefile, since it's only present if you manually run
the doc-diff script. But anybody running "make clean" would
probably want it to go away.
Suggested-by: Eric Sunshine
Signed-off-by: Jeff King
---
> Another fixu
On Thu, Aug 30, 2018 at 05:04:32AM -0400, Eric Sunshine wrote:
> On Thu, Aug 30, 2018 at 3:54 AM Jeff King wrote:
> > Subject: [PATCH] doc-diff: force worktree add
> >
> > We avoid re-creating our temporary worktree if it's already
> > there. But we may run into a s
On Thu, Aug 30, 2018 at 02:18:19PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > It doesn't need to be. As far as I know, the main reasons (from the
> > perspective of a project) to do it through Outreachy are:
> >
> > - being part of a larger program generates attention and gets the
> >interest
On Thu, Aug 30, 2018 at 01:46:00PM +0200, Johannes Schindelin wrote:
> On Wed, 29 Aug 2018, Jeff King wrote:
>
> > - it naturally limits the candidate pool to under-represented groups
> > (which is the whole point of the program, but if you don't
> > actually ca
On Thu, Aug 30, 2018 at 12:16:22PM -0700, Stefan Beller wrote:
> On Wed, Aug 29, 2018 at 7:54 PM Jeff King wrote:
> >
> > On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
> >
> > > > Could you cut down to a real minimal reproduction, i.e.
On Thu, Aug 30, 2018 at 11:50:56AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I can re-roll, or even prepare a patch on top (it's sufficiently subtle
> > that it may merit calling out explicitly in a commit).
>
> Yeah, I tend to agree with your r
On Thu, Aug 30, 2018 at 02:42:01PM -0400, Jeff King wrote:
> > Would "echo base >base" give us 5-byte long base even on Windows?
> > Or the test does not care if it is either "base\n" or "base\r\n"?
> >
> > Just double-checking.
>
&g
On Thu, Aug 30, 2018 at 10:38:21AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +test_expect_success \
> > +'apply delta with too many copied bytes' \
> > +'printf "\5\1\221\0\2" > too_big_copy &&
> > + echo base >ba
On Thu, Aug 30, 2018 at 07:20:49AM +, Eric Wong wrote:
> > At the very least, I think if we plan to reference without an http URL
> > that we would use something like URI-ish, like . That gives
> > tools a better chance to say "OK, I know how to find message-ids"
> > (though I still think
olve this by feeding the already-resolved object id
to git-checkout. That naturally forces a detached HEAD, but
just to make clear our expectation, let's explicitly pass
--detach.
Signed-off-by: Jeff King
---
Another fixup for jk/diff-rendered-docs, noticed when trying it out on
Eric's worktre
y create a
series of duplicate entries. Recent versions now detect and
prevent this, allowing you to override with "-f". Since we
know that the worktree in question was just our temporary
workspace, it's safe for us to always pass "-f".
Signed-off-by: Jeff King
---
Documentation/doc-dif
On Tue, Aug 28, 2018 at 05:20:25PM -0400, Eric Sunshine wrote:
> For consistency with "add -f -f" and "move -f -f" which override
> the lock on a worktree, allow "remove -f -f" to do so, as well, as a
> convenience.
This one makes more sense to me than the last, since "remove -f" already
does
On Tue, Aug 28, 2018 at 05:20:24PM -0400, Eric Sunshine wrote:
> For consistency with "add -f -f", which allows a missing but locked
> worktree path to be re-used, allow "move -f -f" to override a lock,
> as well, as a convenience.
I don't have a strong opinion on this one, as I have never used
On Tue, Aug 28, 2018 at 05:20:23PM -0400, Eric Sunshine wrote:
> For safety, "git worktree add " will refuse to add a new
> worktree at if is already associated with a worktree
> entry, even if is missing (for instance, has been deleted or
> resides on non-mounted removable media or network
On Tue, Aug 28, 2018 at 05:20:22PM -0400, Eric Sunshine wrote:
> A given path should only ever be associated with a single registered
> worktree. This invariant is enforced by refusing to create a new
> worktree at a given path if that path already exists. For example:
>
> $ git worktree add
in a macro; it's ugly, but not as
ugly as writing out each individual conditional.
Signed-off-by: Jeff King
---
patch-delta.c | 21 ++---
t/t5303-pack-corruption-resilience.sh | 2 +-
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/patch
quot; case, which
already handles this correctly.
Signed-off-by: Jann Horn
Signed-off-by: Jeff King
---
patch-delta.c | 5 +++--
t/t5303-pack-corruption-resilience.sh | 30 +++
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/patch
ata != top` sanity check after
the loop to trigger and discard the destination buffer - which means that
the result of the out-of-bounds read is never used for anything.
Signed-off-by: Jann Horn
Signed-off-by: Jeff King
---
patch-delta.c | 2 +-
t/t5303-pack-corrupt
failure and we
don't otherwise use "test-tool delta" in the test suite,
this gives a sanity check that the tool works at all.
These are based on an earlier patch by Jann Horn
.
Signed-off-by: Jeff King
---
t/t5303-pack-corruption-resilience.sh | 59 +++
1 file c
(), but that would defeat the purpose:
strbufs generally overallocate (and at the very least
include a trailing NUL which we do not care about), which
would defeat most memory checkers.
Signed-off-by: Jeff King
---
t/helper/test-delta.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
On Wed, Aug 29, 2018 at 10:58:55PM +0200, Jann Horn wrote:
> If `cmd` is in the range [0x01,0x7f] and `cmd > top-data`, the
> `memcpy(out, data, cmd)` can copy out-of-bounds data from after `delta_buf`
> into `dst_buf`.
>
> This is not an exploitable bug because triggering the bug increments the
On Tue, Aug 28, 2018 at 05:20:20PM -0400, Eric Sunshine wrote:
> prune_worktrees() and delete_git_dir() both remove worktree
> administrative entries from .git/worktrees, and their implementations
> are nearly identical. The only difference is that prune_worktrees() is
> also capable of removing
On Wed, Aug 29, 2018 at 10:02:43AM +, Eric Wong wrote:
> Jeff King wrote:
> > I've thought about mirroring it to a public server as well, just for
> > redundancy. But without the same domain, I'm not sure it would be all
> > that useful as a community resource.
&g
On Wed, Aug 29, 2018 at 04:46:29PM +0200, Johannes Schindelin wrote:
> On Wed, 29 Aug 2018, Jeff King wrote:
>
> > On Mon, Aug 27, 2018 at 03:34:16PM +0200, Johannes Schindelin wrote:
> >
> > > Rather than have a "hack day", I would actually prefer to work w
On Wed, Aug 29, 2018 at 03:12:37PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > 2. To get our landing page and list of projects in order (and also
> > micro-projects for applicants). This can probably build on the
> > previous round at:
> >
> >https://git.github.io/Outreachy-15/
On Wed, Aug 29, 2018 at 10:10:25PM -0400, Gabriel Holodak wrote:
> > Could you cut down to a real minimal reproduction, i.e. just these 20
> > lines or so?
>
> I'm working on getting down to a minimal reproduction, a few lines at
> a time. One thing that seems strange: as I've removed lines,
On Wed, Aug 29, 2018 at 01:46:23PM -0700, Jonathan Nieder wrote:
> > Can you elaborate on that?
>
> What I'm saying is, regardless of the syntax used, as a user I *need*
> a way to look up $some_hash as a sha256-name, with zero risk of Git
> trying to outsmart me and treating $some_hash as a
On Wed, Aug 29, 2018 at 02:03:34PM -0700, Junio C Hamano wrote:
> Andreas Gruenbacher writes:
>
> > Some commands like 'log' default to HEAD if no other revisions are
> > specified on the command line or otherwise. Unfortunately, excludes
> > (^) cancel out that default, so when a command only
On Wed, Aug 29, 2018 at 06:03:53PM -0400, Jeff King wrote:
> Without your second patch applied, this complains about mmap-ing
> /dev/null (or any zero-length file).
>
> Also, \x escapes are sadly not portable (dash, for example, does not
> respect them). You have to use octal
On Wed, Aug 29, 2018 at 05:20:25PM -0400, Jeff King wrote:
> Nice catch. The patch looks good to me, but just to lay out my thought
> process looking for other related problems:
>
> We have two types of instructions:
>
> 1. Take N bytes from position P within the sour
On Wed, Aug 29, 2018 at 10:58:57PM +0200, Jann Horn wrote:
> This verifies the changes from commit "patch-delta: fix oob read".
A minor nit, but usually we'd either introduce tests along with the
fix, or introduce them beforehand as test_expect_failure and then flip
them to success along with
On Wed, Aug 29, 2018 at 05:46:21PM -0400, Jeff King wrote:
> > I think even with ASAN, you'd still need read_in_full() or an mmap()
> > wrapper that fiddles with the ASAN shadow, because mmap() always maps
> > whole pages:
> >
> > $ cat mmap-read-asan-blah.c
>
On Wed, Aug 29, 2018 at 11:40:41PM +0200, Jann Horn wrote:
> > If we want to detect this kind of thing in tests, we should probably be
> > relying on tools like ASan, which would cover all mmaps.
> >
> > It would be nice if there was a low-cost way to detect this in
> > production use, but it
On Wed, Aug 29, 2018 at 10:58:56PM +0200, Jann Horn wrote:
> This ensures that any attempts to access memory directly after the input
> buffer or delta buffer in a delta test will cause a segmentation fault.
>
> Inspired by vsftpd.
Neat trick, but it seems funny to protect this one buffer in
On Wed, Aug 29, 2018 at 02:09:13PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Tue, Aug 28, 2018 at 02:35:25PM -0700, Stefan Beller wrote:
>
> >> Yeah, then let's just convert '/' with as little overhead as possible.
> >
> > Do you care about case
On Wed, Aug 29, 2018 at 02:10:37PM -0700, Stefan Beller wrote:
> > Yes, that makes even the capitalized "CON" issues go away. It's not a
> > one-to-one mapping, though ("foo-" and "foo_" map to the same entity).
>
> foo_ would map to foo__, and foo- would map to something else.
> (foo- as we do
On Wed, Aug 29, 2018 at 10:58:55PM +0200, Jann Horn wrote:
> If `cmd` is in the range [0x01,0x7f] and `cmd > top-data`, the
> `memcpy(out, data, cmd)` can copy out-of-bounds data from after `delta_buf`
> into `dst_buf`.
>
> This is not an exploitable bug because triggering the bug increments the
601 - 700 of 13736 matches
Mail list logo
