On 10/22/19 3:53 PM, Theodore Y. Ts'o wrote:
On Tue, Oct 22, 2019 at 02:11:22PM +0200, Vegard Nossum wrote:
As I wrote in there, we could already today start using
git am --message-id
when applying patches and this would provide something that a bot could
annotate with git
On 10/20/19 8:28 AM, Vegard Nossum wrote:
On 10/20/19 5:17 AM, Willy Tarreau wrote:
On Fri, Oct 18, 2019 at 03:14:56PM -0400, Theodore Y. Ts'o wrote:
On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:
The problem I ran into with putting the metadata at the end was
detecting
result) as opposed to trying
to parse the metadata and pass it piecewise to commit_tree().
Previous-version: 3120370db89f32e07a082edb4722db8feef1
Cc: Paul Tan
Signed-off-by: Vegard Nossum
---
Documentation/git-am.txt | 9 +++-
builtin/am.c | 111
d as part of the diff,
and although the metadata now appears between the diff and the signature
(and is extracted into its own file) the signature is also output together
with the diff; this breaks no existing test cases and seems to be the most
backwards compatible.
Signed-off-by: Vegard Nossum
fig option controlling the default behaviour:
format.complete
Signed-off-by: Vegard Nossum
Previous-version: 622a0469a4970c5daac0c0323e2d6a77b3bebbdb
---
Documentation/config/format.txt| 7 ++
Documentation/git-format-patch.txt | 9
builtin/log.c
[I'm intentionally keeping the recipient list short to avoid hitting
the Oracle spam filter on outgoing email, hopefully everybody on the
git side who is interested will receive this via the mailing list and
I will link this submission from the workflows list too.]
Background:
There seems to be a
On 10/20/19 5:17 AM, Willy Tarreau wrote:
On Fri, Oct 18, 2019 at 03:14:56PM -0400, Theodore Y. Ts'o wrote:
On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:
The problem I ran into with putting the metadata at the end was
detecting where the diff ends. A comment in '
On 10/18/19 6:15 PM, Theodore Y. Ts'o wrote:
On Fri, Oct 18, 2019 at 04:27:48PM +0200, Vegard Nossum wrote:
commit ac30b08065cd55362a7244a3bbc8df3563cefaaa
tree 8f09d9d6ed78f8617b2fe54fe9712990ba808546
parent 108b97dc372828f0e72e56bbb40cae8e1e83ece6
author Vegard Nossum 1570284959
On 10/16/19 4:45 PM, Santiago Torres Arias wrote:
Hi Willy, Vegard.
On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:
Hi Vegard,
On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:
(cross-posted to git, LKML, and the kernel workflows mailing lists.)
Hi all,
I&#x
On 10/17/19 3:11 PM, Theodore Y. Ts'o wrote:
On Thu, Oct 17, 2019 at 02:23:58PM +0200, Vegard Nossum wrote:
Of course, this relies strongly on actually having (correct) sha1
references to previous versions inside the changelog. In my original
idea, this reference would only appear insid
On 10/17/19 5:17 AM, Junio C Hamano wrote:
Vegard Nossum writes:
Step 1:
* git send-email needs to include parent SHA1s and generally all the
information needed to perfectly recreate the commit when applied so
that all the SHA1s remain the same
* git am (or an alternative command
On 10/16/19 10:57 PM, Jonathan Nieder wrote:
Hi,
A few small points.
Vegard Nossum wrote:
* git am (or an alternative command) needs to recreate the commit
perfectly when applied, including applying it to the correct parent
Interesting. "git format-patch" has a --base option
On 10/16/19 5:00 PM, Pratyush Yadav wrote:
On 16/10/19 12:22PM, Vegard Nossum wrote:
Just to play the devil's advocate, even though I'm in favor of something
like this, I'll add in another disadvantage:
- The maintainer can't make small edits before pushing the changes o
cho $merge
}
This will open the editor to edit the patchset description and create a
merge commit that encompasses the patches in the patchset (use sha1^- to
view the patches in it).
>From 622a0469a4970c5daac0c0323e2d6a77b3bebbdb Mon Sep 17 00:00:00 2001
From: Vegard Nossum
Date: Sat, 5 Oct 2019 16:15:59 +0200
Subject:
On 13/03/2017 18:11, Junio C Hamano wrote:
Vegard Nossum writes:
However, I think it's more useful to think of these testcases not as
"binary test that nobody knows what they are doing", but as "(sometimes
invalid) packfiles which tickle interesting code paths in the pac
On 12/03/2017 19:14, Junio C Hamano wrote:
Jeff King writes:
One further devil's advocate:
If people really _do_ care about coverage, arguably the AFL tests are a
pollution of that concept. Because they are running the code, but doing
a very perfunctory job of testing it. IOW, our coverage of
ld that help at all?
Vegard
>From 04446ce562eee129588f2c92c4eef2c82ed4bb4f Mon Sep 17 00:00:00 2001
From: Vegard Nossum
Date: Sun, 12 Mar 2017 14:35:25 +0100
Subject: [PATCH] test-lib: add --fuzzing option
>From t/README:
This causes additional testcases found by fuzzing to be run,
f
On 10/03/2017 20:42, Jeff King wrote:
That's something I guess, but I'm not enthused by the idea of just
dumping a bunch of binary test cases that nobody, not even the author,
understands.
[...]
My real concern is that this is the tip of the ice berg. So we increased
coverage in one program by
On 10/03/2017 20:06, Jeff King wrote:
On Fri, Mar 10, 2017 at 04:15:56PM +0100, Vegard Nossum wrote:
I've used AFL to generate a corpus of pack files that maximises the edge
coverage for 'git index-pack'.
This is a supplement to (and not a replacement for) the regular test case
On 10/03/2017 16:15, Vegard Nossum wrote:
I've used AFL to generate a corpus of pack files that maximises the edge
coverage for 'git index-pack'.
This is a supplement to (and not a replacement for) the regular test cases
where we know exactly what each test is checking for. Thes
's
convenience. I listed you as the author, since you did the hard part. If
you're OK with it, please indicate that it's OK to add your
signed-off-by. If you prefer to do it differently, feel free to post
your own patch.
Thanks.
-- >8 --
From: Vegard Nossum
Subject: [PATCH] lin
On 04/03/2017 20:49, Vegard Nossum wrote:
On 04/03/2017 19:08, Vegard Nossum wrote:
On 04/03/2017 18:23, Lars Schneider wrote:
Did Travis find our first 32bit bug? I briefly looked into it
and the following new topic on pu seems to cause the issue:
http://public-inbox.org/git
On 04/03/2017 19:08, Vegard Nossum wrote:
On 04/03/2017 18:23, Lars Schneider wrote:
Did Travis find our first 32bit bug? I briefly looked into it
and the following new topic on pu seems to cause the issue:
http://public-inbox.org/git/20170302172902.16850-1-allan.x.xav...@oracle.com/
https
On 04/03/2017 18:23, Lars Schneider wrote:
Did Travis find our first 32bit bug? I briefly looked into it
and the following new topic on pu seems to cause the issue:
http://public-inbox.org/git/20170302172902.16850-1-allan.x.xav...@oracle.com/
https://github.com/git/git/commit/aaae0bf787f09ba102f
On 25/02/2017 12:59, Philip Oakley wrote:
From: "Vegard Nossum"
If we have a patch like the one in the new test-case, then we will
"the one in the new test-case" needs a clearer reference to the
particular case so that future readers will know what it refers to.
Notice
The patch file is completely bogus as it tries to rename something
that is known not to exist, so we can throw an error for this.
Found using AFL.
Signed-off-by: Vegard Nossum
---
apply.c | 3 ++-
t/t4154-apply-git-header.sh | 15 +++
2 files changed, 17 insertions(+)
For the patches in the added testcases, we were crashing with:
git-apply: apply.c:3665: check_preimage: Assertion `patch->is_new <= 0'
failed.
As it turns out, check_preimage() is prepared to handle these conditions,
so we can remove the assertion.
Found using AFL.
Signed-off
On 11/02/2017 04:12, Junio C Hamano wrote:
René Scharfe writes:
Am 10.02.2017 um 23:24 schrieb Junio C Hamano:
* vn/xdiff-func-context (2017-01-15) 1 commit
- xdiff -W: relax end-of-file function detection
"git diff -W" has been taught to handle the case where a new
function is added at t
On 15/01/2017 03:39, Junio C Hamano wrote:
René Scharfe writes:
I am also more focused on keeping the codebase maintainable in good
health by making sure that we made an effort to find a solution that
is general-enough before solving a single specific problem you have
today. We may end up dec
On 13/01/2017 20:51, Junio C Hamano wrote:
René Scharfe writes:
That's true, but I'm not sure "non-empty line before function line" is
good enough a definition for desirable lines. It wouldn't work for
people who don't believe in empty lines. Or for those that put a
blank line between comment
show that the tests do not break even when changing the behaviour of
'diff -W' in the previous commits.
Cc: René Scharfe
Signed-off-by: Vegard Nossum
---
t/t4051-diff-function-context.sh | 2 +-
t/t4051/appended1.c | 3 ++-
t/t4051/dummy.c | 3
of
the detected function start until we hit the first non-blank line.
Cc: René Scharfe
Signed-off-by: Vegard Nossum
---
xdiff/xemit.c | 4
1 file changed, 4 insertions(+)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 8c88dbd..3a3060d 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
rsion.
This fixes the case where we add e.g.
// Begin of dummy
static int dummy(void)
{
}
to the end of the file.
Cc: René Scharfe
Signed-off-by: Vegard Nossum
---
xdiff/xemit.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/
The --inter-hunk-context= option was added in commit 6d0e674a5754
("diff: add option to show context between close hunks"). This patch
allows configuring a default for this option.
Cc: René Scharfe
Cc: Pranit Bauva
Signed-off-by: Vegard Nossum
---
v2:
- Update Documentation/diff-
The --inter-hunk-context= option was added in commit 6d0e674a5754
("diff: add option to show context between close hunks"). This patch
allows configuring a default for this option.
Cc: René Scharfe
Signed-off-by: Vegard Nossum
---
Documentation/diff-options.txt | 2
On 10/13/2016 10:43 PM, Jeff King wrote:
No problem. I do think you'll benefit a lot from packing everything into
a single pack, but it's also clear that Git was doing more work than it
needed to be. This was a known issue when we added the racy-check to
has_sha1_file(), and knew that we might ha
On 10/13/2016 05:26 PM, Jeff King wrote:
On Thu, Oct 13, 2016 at 09:20:07AM +0200, Vegard Nossum wrote:
Does the patch below help?
Yes, ~2m10s -> ~1m25s when I test a git fetch this morning (the other
variation in time may be due to different CPU usage by other programs,
but I ran w
On 10/13/2016 12:45 AM, Junio C Hamano wrote:
> Vegard Nossum writes:
>
>> A closer inspection reveals the problem to really be that this is an
>> extremely hot path with more than -- holy cow -- 4,106,756,451
>> iterations on the 'packed_git' list for a sing
On 10/13/2016 01:47 AM, Jeff King wrote:
On Wed, Oct 12, 2016 at 07:18:07PM -0400, Jeff King wrote:
Also, is it possible to make the repository in question available? I
might be able to reproduce based on your description, but it would save
time if I could directly run gdb on your example.
I
On 10/13/2016 01:01 AM, Jeff King wrote:
On Thu, Oct 13, 2016 at 12:30:52AM +0200, Vegard Nossum wrote:
However, the commit found by 'git blame' above appears just fine to me,
I haven't been able to spot a bug in it.
A closer inspection reveals the problem to really be
Hi all,
I've bisected a performance regression (noticed by Quentin and myself)
which caused a 'git fetch' to go from ~1m30s to ~2m40s:
commit 47bf4b0fc52f3ad5823185a85f5f82325787c84b
Author: Jeff King
Date: Mon Jun 30 13:04:03 2014 -0400
prepare_packed_git_one: refactor duplicate-pack ch
rev". For example, for a
two-parent merge, you can use rev^-2 to get the set of commits which were
made to the main branch while the topic branch was prepared.
Signed-off-by: Vegard Nossum
---
[v2: Use ^- instead of % as suggested by Junio Hamano and use some
common helper functions for parsin
an use rev^-2
to get the set of commits which were made to the main branch while the
topic branch was prepared.
Signed-off-by: Vegard Nossum
---
[v2: Use ^- instead of % as suggested by Junio Hamano and use some
common helper functions for parsing.]
[v3: Use 'struct object_id' inst
an use rev^-2
to get the set of commits which were made to the main branch while the
topic branch was prepared.
Signed-off-by: Vegard Nossum
---
[v2: Use ^- instead of % as suggested by Junio Hamano and use some
common helper functions for parsing.]
[v3: Use 'struct object_id' inst
or parsing.]
Signed-off-by: Vegard Nossum
---
Documentation/revisions.txt | 14 +++
builtin/rev-parse.c | 28 ++
revision.c | 91 +
revision.h | 1 +
4 files changed, 134 insertions(+)
diff --git Doc
ia the nth parent,
but this might be questionable/unintuitive in case any of the parents
that share commits (as you would get fewer commits than expected).
Signed-off-by: Vegard Nossum
---
Documentation/revisions.txt | 14 +
builtin/rev-parse.c
46 matches
Mail list logo
