se changes.
Thanks, -Stolee
Derrick Stolee (2):
commit-graph: clean up leaked memory during write
commit-graph: reduce initial oid allocation
commit-graph.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
base-commit: 6b89a34c89fc763292f06012318b852b74825619
Published-
On 10/1/2018 3:16 PM, René Scharfe wrote:
Am 28.06.2018 um 14:31 schrieb Derrick Stolee via GitGitGadget:
diff --git a/commit-reach.c b/commit-reach.c
index c58e50fbb..ac132c8e4 100644
--- a/commit-reach.c
+++ b/commit-reach.c
@@ -513,65 +513,88 @@ int commit_contains(struct ref_filter *filter
On 9/28/2018 11:31 AM, Ramsay Jones wrote:
Also, this is not the first time some multi-threaded code in git
has 'failed' by assuming more than one cpu, so ...
I wonder if this is a good time to create a GIT_TEST_CPU_COUNT variable
so we can mock out single-processor environments instead of
On 9/29/2018 7:00 PM, Stefan Xenos wrote:
Hello, List!
Hello! Welcome.
I'm interested in porting something like Mercurial's evolve command to
Git. I'll be following up with a formal proposal shortly, but before I
do I thought I'd introduce myself to the list and find out if anyone
else is
and looks good to me.
Reviewed-by: Derrick Stolee
On 9/21/2018 1:39 PM, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
When running a command like 'git rev-list --topo-order HEAD',
Git performed the following steps:
1. Run limit_list(), which parses all reachable commits,
adds them to a linked list, and distributes
On 9/27/2018 12:01 PM, Ævar Arnfjörð Bjarmason wrote:
I had an IRC conversation with Johannes saying I didn't know Git For
Windows builds perfectly well for Linux, this just isn't advertised in
the ANNOUNCE E-Mails, so I hadn't tried.
We run CI to ensure it builds and tests on Mac OSX, too.
On 9/27/2018 11:21 AM, Ben Peart wrote:
On 9/26/2018 2:54 PM, Derrick Stolee wrote:
GIT_TEST_INDEX_THREADS=1
Because the test repos are so small (ie smaller than 10K files), the
test suite already executes as if GIT_TEST_INDEX_THREADS=1 is set (ie
single threaded). I added the test
On 9/27/2018 11:14 AM, Ben Peart wrote:
On 9/26/2018 2:44 PM, Derrick Stolee wrote:
On 9/26/2018 1:59 PM, Junio C Hamano wrote:
Derrick Stolee writes:
Perhaps removing the middle columns of data and just " )
" would be easier? We could also remove tabs to save space. Fo
On 9/21/2018 1:39 PM, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
When consuming a priority queue, it can be convenient to inspect
the next object that will be dequeued without actually dequeueing
it. Our existing library did not have such a 'peek' operation, so
add
On 9/26/2018 2:43 PM, Thomas Gummerer wrote:
On 09/26, Derrick Stolee wrote:
This is a bit tricky to do, but I will investigate. For some things, the
values can conflict with each other (GIT_TEST_SPLIT_INDEX doesn't play
nicely with other index options, I think).
Just commenting on this point
On 9/26/2018 1:59 PM, Junio C Hamano wrote:
Derrick Stolee writes:
In an effort to ensure new code is reasonably covered by the test
suite, we now have contrib/coverage-diff.sh to combine the gcov output
from 'make coverage-test ; make coverage-report' with the output from
'git diff A B
On 9/26/2018 6:56 AM, Jason Pyeron wrote:
-Original Message-
From: Derrick Stolee
Sent: Wednesday, September 26, 2018 6:43 AM
On 9/25/2018 5:12 PM, Ben Peart wrote:
On 9/25/2018 2:42 PM, Derrick Stolee wrote:
In an effort to ensure new code is reasonably covered by the test
suite, we
On 9/25/2018 5:12 PM, Ben Peart wrote:
On 9/25/2018 2:42 PM, Derrick Stolee wrote:
In an effort to ensure new code is reasonably covered by the test
suite, we now have contrib/coverage-diff.sh to combine the gcov
output from 'make coverage-test ; make coverage-report' with the
output from
coverage can be improved.
Thanks,
-Stolee
---
master@{1}..master:
builtin/remote.c
5025425dfff ( Shulhan 2018-09-13 20:18:33 +0700
864) return error(_("No such remote: '%s'"), name);
commit-reach.c
b67f6b26e35 (Derrick Stolee 2018-09-21 08:05:26
On 9/25/2018 2:06 PM, Junio C Hamano wrote:
Derrick Stolee writes:
@@ -622,10 +623,7 @@ int can_all_from_reach_with_flag(struct object_array *from,
}
cleanup:
- for (i = 0; i < nr_commits; i++) {
- clear_commit_marks(list[i], RES
On 9/25/2018 3:06 AM, Patrick Steinhardt wrote:
On Mon, Sep 24, 2018 at 11:32:23PM +0200, SZEDER Gábor wrote:
On Mon, Sep 24, 2018 at 02:15:30PM -0700, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
The index v4 format has been available since 2012 with 9d22778
"reach-ca
From: Derrick Stolee
Due to a regression introduced by 4fbcca4e "commit-reach: make
can_all_from_reach... linear" the series including b67f6b26
"commit-reach: properly peel tags" was merged to master quickly.
There were a few more cleanups left to apply in the series
On 9/24/2018 6:06 PM, Junio C Hamano wrote:
* ds/reachable (2018-09-21) 2 commits
(merged to 'next' on 2018-09-21 at d4cd62108e)
+ commit-reach: fix memory and flag leaks
+ commit-reach: properly peel tags
Recent update broke the reachability algorithm when refs (e.g.
tags) that
From: Derrick Stolee
The index v4 format has been available since 2012 with 9d22778
"reach-cache.c: write prefix-compressed names in the index". Since
the format has been stable for so long, almost all versions of Git
in use today understand version 4, removing one barrier
of Git.
Personally, I'm not an expert here, but I am happy to start the
conversation.
Thanks, -Stolee
Derrick Stolee (1):
read-cache: update index format default to v4
read-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 53f9a3e157dbbc901a02ac2c73346d375e24978c
n-commit objects.
[1]
https://public-inbox.org/git/0bf9103c-9377-506b-7ad7-e5273d8e9...@gmail.com/T/#u
Derrick Stolee (1):
commit-reach: properly peel tags and clear flags
commit-reach.c| 44 +--
t/helper/test-reach.c | 22 +-
t/
From: Derrick Stolee
The can_all_from_reach_with_flag() algorithm was refactored in 4fbcca4e
"commit-reach: make can_all_from_reach... linear" but incorrectly
assumed that all objects provided were commits. During a fetch
negotiation, ok_to_give_up() in upload-pack.c may provide unp
On 9/21/2018 7:58 PM, Jeff King wrote:
On Fri, Sep 21, 2018 at 08:05:27AM -0700, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
The can_all_from_reach_with_flag() method uses 'assign_flag' as a
value we can use to mark objects temporarily during our commit walk.
The intent
automated approach catching everything, so I
looked carefully at this patch. There are still a lot of things
happening that we would not recommend doing in new tests.
Reported-by: Derrick Stolee
Reported-by: Jeff Hostetler
Signed-off-by: Stefan Beller
---
t/t7001-mv.sh | 268
On 9/21/2018 7:56 PM, Jeff King wrote:
On Fri, Sep 21, 2018 at 08:05:26AM -0700, Derrick Stolee via GitGitGadget wrote:
+ if (!from_one || from_one->type != OBJ_COMMIT) {
+ /* no way to tell if this is reachable by
+* look
" instead of "0".
This causes t3420-rebase-autostash.sh to fail, as that test watches the
full output of the rebase command, including commit runs. The following
patch fixes the problem, but could probably be squashed into a merge or
other commit.
Thanks,
-Stolee
-->8--
From: Derri
On 9/20/2018 11:35 AM, Ramsay Jones wrote:
On 20/09/18 00:38, Derrick Stolee wrote:
On 9/18/2018 8:15 PM, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
commit-reach.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/commit-reach.h b/commit-reach.h
index
On 9/21/2018 1:05 PM, Junio C Hamano wrote:
Ramsay Jones writes:
BTW, I notice that patch #9 (commit-reach.h: add missing declarations
(hdr-check)) didn't make it onto 'pu' - was there something else I
needed to do? (I am still in two minds about sending an RFC patch
on-top of patch #9).
I
From: Derrick Stolee
There are a few things that need to move around a little before
making a big refactoring in the topo-order logic:
1. We need access to record_author_date() and
compare_commits_by_author_date() in revision.c. These are used
currently by sort_in_topological_order
From: Derrick Stolee
When running a command like 'git rev-list --topo-order HEAD',
Git performed the following steps:
1. Run limit_list(), which parses all reachable commits,
adds them to a linked list, and distributes UNINTERESTING
flags. If all unprocessed commits are UNINTERESTING
From: Derrick Stolee
The rev-list command is critical to Git's functionality. Ensure it
works in the three commit-graph environments constructed in
t6600-test-reach.sh. Here are a few important types of rev-list
operations:
* Basic: git rev-list --topo-order HEAD
* Range: git rev-list --topo
From: Derrick Stolee
In anticipation of adding longer flag names in the next change, add
an extra tab to each flag definition in revision.h.
Signed-off-by: Derrick Stolee
---
revision.h | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git
From: Derrick Stolee
When running 'git rev-list --topo-order' and its kin, the topo_order
setting in struct rev_info implies the limited setting. This means
that the following things happen during prepare_revision_walk():
* revs->limited implies we run limit_list() to walk the ent
From: Derrick Stolee
When consuming a priority queue, it can be convenient to inspect
the next object that will be dequeued without actually dequeueing
it. Our existing library did not have such a 'peek' operation, so
add it as prio_queue_peek().
Add a reference-level comparison in t/helper
From: Derrick Stolee
The 'test_three_modes' method assumes we are using the 'test-tool
reach' command for our test. However, we may want to use the data
shape of our commit graph and the three modes (no commit-graph,
full commit-graph, partial commit-graph) for other git commands.
Split
ed.blob.core.windows.net/media/2018/06/commit-graph-topo-order-b-a.png
Animation showing three-part walk
[3] https://github.com/derrickstolee/git/tree/topo-order/testA branch
containing this series along with commits to compute commit-graph in entire
test suite.
Cc: avarab@gmail.comCc: szeder...
On 9/18/2018 2:05 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Sep 18 2018, Derrick Stolee via GitGitGadget wrote:
Thanks. Good to see the commit graph used for more stuff.
On the Linux repository, I got the following performance results when
comparing to the previous version with or without
On 9/21/2018 11:15 AM, Derrick Stolee via GitGitGadget wrote:
For example, I ran this against the 'next' branch (22e244b)
versus 'master' (150f307) and got the following output:
fsck.c
fb8952077df (René Scharfe 2018-09-03 14:49:26 + 212)
die_errno("Could not rea
From: Derrick Stolee
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
This leaves the repo in a state where every X.c file that was covered has
197)
ctx->show_object(obj, base->buf, ctx->show_data);
ll-merge.c
d64324cb60e (Torsten Bögershausen 2018-09-12 21:32:02 +0200 379)
marker_size = DEFAULT_CONFLICT_MARKER_SIZE;
midx.c
56ee7ff1565 (Derrick Stolee 2018-09-13 11:02:13 -
From: Derrick Stolee
The can_all_from_reach_with_flag() method uses 'assign_flag' as a
value we can use to mark objects temporarily during our commit walk.
The intent is that these flags are removed from all objects before
returning. However, this is not the case.
The 'from' array could also
n-commit objects.
[1]
https://public-inbox.org/git/0bf9103c-9377-506b-7ad7-e5273d8e9...@gmail.com/T/#u
Derrick Stolee (2):
commit-reach: properly peel tags
commit-reach: fix memory and flag leaks
commit-reach.c| 41 ++---
t/helper/test-reach.c | 22
From: Derrick Stolee
The can_all_from_reach_with_flag() algorithm was refactored in 4fbcca4e
"commit-reach: make can_all_from_reach... linear" but incorrectly
assumed that all objects provided were commits. During a fetch
negotiation, ok_to_give_up() in upload-pack.c may provide unp
On 9/21/2018 10:40 AM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Sep 21 2018, Derrick Stolee wrote:
This error was reported by Peff [1] and fixed in [2], but as stated
[3] I was waiting for more review before sending a v3. I'll send that
v3 shortly, responding to the feedback so far.
-Stolee
On 9/21/2018 10:30 AM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Sep 21 2018, Junio C Hamano wrote:
* ds/reachable (2018-08-28) 19 commits
(merged to 'next' on 2018-08-28 at b1634b371d)
+ commit-reach: correct accidental #include of C file
(merged to 'next' on 2018-08-22 at 17f3275afb)
On 9/20/2018 9:38 AM, Martin Ågren wrote:
On Thu, 20 Sep 2018 at 14:50, Derrick Stolee wrote:
On 9/19/2018 12:30 PM, Martin Ågren wrote:
The full name, by the way, is not the "commit-graph file" with a dash,
cf. the synopsis. Use the dashless form. (The next commit will fix the
rem
On 9/19/2018 5:21 PM, Martin Ågren wrote:
On Wed, 19 Sep 2018 at 23:04, Ævar Arnfjörð Bjarmason wrote:
Fix a regression in my recent 7b0f229222 ("commit-graph write: add
progress output", 2018-09-17), the newly added progress output for
"commit-graph write" didn't check the --quiet option.
On 9/19/2018 12:30 PM, Martin Ågren wrote:
This document sometimes refers to the "commit graph file" as just "the
graph file". This saves a couple of words here and there at the risk of
confusion. In particular, the documentation for `git commit-graph read`
appears to suggest that there are
On 9/19/2018 12:30 PM, Martin Ågren wrote:
While we're here, fix an instance of "folder" to be "directory".
These changes are clearly good. Thanks!
;
+struct pack_entry;
+
struct multi_pack_index {
struct multi_pack_index *next;
Thanks for catching this!
Reviewed-by: Derrick Stolee
On 9/18/2018 8:15 PM, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
commit-reach.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/commit-reach.h b/commit-reach.h
index 7d313e2975..f41d8f6ba3 100644
--- a/commit-reach.h
+++ b/commit-reach.h
@@ -1,12 +1,13 @@
On 9/19/2018 12:30 PM, Martin Ågren wrote:
We have a couple of bullet items which span multiple lines, and where we
have prefixed each line with a `*`. (This might be the result of a text
editor trying to help.) This results in each line being typeset as a
separate bullet item. Drop the extra
From: Derrick Stolee
There are a few things that need to move around a little before
making a big refactoring in the topo-order logic:
1. We need access to record_author_date() and
compare_commits_by_author_date() in revision.c. These are used
currently by sort_in_topological_order
Graph III: Generations and Graph Algorithms
[2]
https://msdnshared.blob.core.windows.net/media/2018/06/commit-graph-topo-order-b-a.png
Animation showing three-part walk
[3] https://github.com/derrickstolee/git/tree/topo-order/testA branch
containing this series along with commits to compute commit-graph in e
From: Derrick Stolee
The rev-list command is critical to Git's functionality. Ensure it
works in the three commit-graph environments constructed in
t6600-test-reach.sh. Here are a few important types of rev-list
operations:
* Basic: git rev-list --topo-order HEAD
* Range: git rev-list --topo
From: Derrick Stolee
When consuming a priority queue, it can be convenient to inspect
the next object that will be dequeued without actually dequeueing
it. Our existing library did not have such a 'peek' operation, so
add it as prio_queue_peek().
Add a reference-level comparison in t/helper
From: Derrick Stolee
When running a command like 'git rev-list --topo-order HEAD',
Git performed the following steps:
1. Run limit_list(), which parses all reachable commits,
adds them to a linked list, and distributes UNINTERESTING
flags. If all unprocessed commits are UNINTERESTING
From: Derrick Stolee
When running 'git rev-list --topo-order' and its kin, the topo_order
setting in struct rev_info implies the limited setting. This means
that the following things happen during prepare_revision_walk():
* revs->limited implies we run limit_list() to walk the ent
From: Derrick Stolee
The 'test_three_modes' method assumes we are using the 'test-tool
reach' command for our test. However, we may want to use the data
shape of our commit graph and the three modes (no commit-graph,
full commit-graph, partial commit-graph) for other git commands.
Split
On 9/14/2018 7:26 PM, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
Hi Derrick,
If you need to re-roll your 'ds/multi-pack-verify' branch, could you
please squash this into the relevant patch (commit 64cbf3df21,
"multi-pack-index: add 'verify' verb", 2018-09-13).
[noticed by sparse].
On 9/14/2018 5:56 PM, Junio C Hamano wrote:
* ds/format-commit-graph-docs (2018-08-21) 2 commits
- commit-graph.txt: improve formatting for asciidoc
- Docs: Add commit-graph tech docs to Makefile
Design docs for the commit-graph machinery is now made into HTML as
well as text.
Will
On 9/13/2018 1:40 PM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
+ then
+ line_num=$(($line_num + 1))
+ fi
+ fi
+ done
I have a feeling that a single Perl scri
From: Derrick Stolee
The multi-pack-index builtin writes multi-pack-index files, and
uses a 'write' verb to do so. Add a 'verify' verb that checks this
file matches the contents of the pack-indexes it replaces.
The current implementation is a no-op, but will be extended in
small increments
From: Derrick Stolee
When verifying a multi-pack-index, the only action that takes
significant time is checking the object offsets. For example,
to verify a multi-pack-index containing 6.2 million objects in
the Linux kernel repository takes 1.3 seconds on my machine.
99% of that time is spent
From: Derrick Stolee
The final check we make while loading a multi-pack-index is that
the packfile names are in lexicographical order. Make this error
be a die() instead.
In order to test this condition, we need multiple packfiles.
Earlier in t5319-multi-pack-index.sh, we tested the interaction
From: Derrick Stolee
The 'git multi-pack-index verify' command must verify the object
offsets stored in the multi-pack-index are correct. There are two
ways the offset chunk can be incorrect: the pack-int-id and the
object offset.
Replace the BUG() statement with a die() statement, now that we
From: Derrick Stolee
When loading a 64-bit offset, we intend to check that off_t can store
the resulting offset. However, the condition accidentally checks the
32-bit offset to see if it is smaller than a 64-bit value. Fix it,
and this will be covered by a test in the 'git multi-pack-index
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
midx.c | 16
t/t5319-multi-pack-index.sh | 5 +
2 files changed, 21 insertions(+)
diff --git a/midx.c b/midx.c
index e655a15aed..a02b19efc1 100644
--- a/midx.c
+++ b/midx.c
@@ -926,13 +926,29
From: Derrick Stolee
When core.multiPackIndex is true, we may have a multi-pack-index
in our object directory. Add calls to 'git multi-pack-index verify'
at the end of 'git fsck' if so.
Signed-off-by: Derrick Stolee
---
builtin/fsck.c | 18 ++
t/t5319-multi-pack
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
midx.c | 11 +++
t/t5319-multi-pack-index.sh | 8
2 files changed, 19 insertions(+)
diff --git a/midx.c b/midx.c
index dfd26b4d74..06d5cfc826 100644
--- a/midx.c
+++ b/midx.c
@@ -959,5 +959,16 @@ int
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
midx.c | 3 +++
t/t5319-multi-pack-index.sh | 13 +
2 files changed, 16 insertions(+)
diff --git a/midx.c b/midx.c
index ec78254bb6..8b054b39ab 100644
--- a/midx.c
+++ b/midx.c
@@ -100,6 +100,9 @@ struct
From: Derrick Stolee
When verifying if a multi-pack-index file is valid, we want the
command to fail to signal an invalid file. Previously, we wrote
an error to stderr and continued as if we had no multi-pack-index.
Now, die() instead of error().
Add tests that check corrupted headers in a few
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
midx.c | 9 +
t/t5319-multi-pack-index.sh | 8
2 files changed, 17 insertions(+)
diff --git a/midx.c b/midx.c
index a02b19efc1..dfd26b4d74 100644
--- a/midx.c
+++ b/midx.c
@@ -950,5 +950,14 @@ int
d a commit that provides progress updates when
checking object offsets.
Based on ds/multi-pack-index
[1]
https://public-inbox.org/git/20180904202729.13900-1-ava...@gmail.com/T/#u
Derrick Stolee (11):
multi-pack-index: add 'verify' verb
multi-pack-index: verify bad header
multi-pack-ind
On 9/13/2018 1:17 AM, brian m. carlson wrote:
This is the next in the series of improvements to make tests
hash-independent.
A range-diff is below.
Changes from v4:
* Add local statements to the &&-chain.
* Fix a typo in the local statement.
* Add a helpful comment about why test_detect_hash
On 9/13/2018 12:10 PM, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
The can_all_from_reach_with_flag() algorithm was refactored in 4fbcca4e
"commit-reach: make can_all_from_reach... linear" but incorrectly
assumed that all objects provided were commits. Duri
From: Derrick Stolee
The can_all_from_reach_with_flag() algorithm was refactored in 4fbcca4e
"commit-reach: make can_all_from_reach... linear" but incorrectly
assumed that all objects provided were commits. During a fetch
negotiation, ok_to_give_up() in upload-pack.c may provide unp
n-commit objects.
[1]
https://public-inbox.org/git/0bf9103c-9377-506b-7ad7-e5273d8e9...@gmail.com/T/#u
Derrick Stolee (1):
commit-reach: properly peel tags
commit-reach.c| 33 ++---
t/helper/test-reach.c | 22 +-
t/t6600-test-reach.sh | 30 +++
From: Derrick Stolee
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
This leaves the repo in a state where every X.c file that was covered has
t:
builtin/commit.c
859fdc0c3cf (Derrick Stolee 2018-08-29 05:49:04 -0700 1657)
write_commit_graph_reachable(get_object_directory(), 0);
builtin/rev-list.c
250edfa8c87 (Harald Nordgren2018-04-18 23:05:35 +0200 431)
bisect_flags |= BISECT_FIND_ALL
On 9/12/2018 6:54 PM, Junio C Hamano wrote:
Junio C Hamano writes:
"Derrick Stolee via GitGitGadget" writes:
contrib/coverage-diff.sh | 70
1 file changed, 70 insertions(+)
create mode 100755 contrib/coverage-diff.sh
I fully
On 9/12/2018 12:45 PM, Derrick Stolee via GitGitGadget wrote:
For example, I ran this against the 'jch' branch (d3c0046)
versus 'next' (dd90340)
As another example, I ran this against the 'pu' branch (4c416a53) versus
'jch' (d3c0046) and got the following output, submitted here without
t:
builtin/commit.c
859fdc0c3cf (Derrick Stolee 2018-08-29 05:49:04 -0700 1657)
write_commit_graph_reachable(get_object_directory(), 0);
builtin/rev-list.c
250edfa8c87 (Harald Nordgren2018-04-18 23:05:35 +0200 431)
bisect_flags |= BISECT_FIND_ALL
From: Derrick Stolee
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
This leaves the repo in a state where every X.c file that was covered has
From: Derrick Stolee
The commit 40ce4160 "format-patch: allow --range-diff to apply to
a lone-patch" added the ability to see a range-diff as commentary
after the commit message of a single patch series (i.e. [PATCH]
instead of [PATCH X/N]). However, this functionality was not
covered
...@sunshine.co
Cc: p...@peff.net
[1]
https://github.com/derrickstolee/git/blob/coverage/contrib/coverage-diff.shA
bash script to report uncovered lines that were added in a diff.
Derrick Stolee (1):
t3206-range-diff.sh: cover single-patch case
t/t3206-range-diff.sh | 5 +
1 file changed, 5
From: Derrick Stolee
The can_all_from_reach_with_flag() algorithm was refactored in 4fbcca4e
"commit-reach: make can_all_from_reach... linear" but incorrectly
assumed that all objects provided were commits. During a fetch
negotiation, ok_to_give_up() in upload-pack.c may provide unp
...@gmail.com/T/#u
Derrick Stolee (1):
commit-reach: properly peel tags
commit-reach.c| 25 ++---
t/helper/test-reach.c | 22 +-
t/t6600-test-reach.sh | 30 --
3 files changed, 63 insertions(+), 14 deletions(-)
base-commit
On 9/11/2018 5:34 PM, Eric Sunshine wrote:
On Tue, Sep 11, 2018 at 4:26 PM Derrick Stolee via GitGitGadget
wrote:
The commit 40ce4160 "format-patch: allow --range-diff to apply to
a lone-patch" added the ability to see a range-diff as commentary
after the commit message of a si
On 9/12/2018 12:29 AM, Jeff King wrote:
On Wed, Sep 12, 2018 at 12:14:25AM -0400, Jeff King wrote:
+ ALLOC_ARRAY(list, from->nr);
for (i = 0; i < from->nr; i++) {
- struct object *from_one = from->objects[i].item;
+ list[i] = (struct commit
On 9/11/2018 4:21 PM, Derrick Stolee via GitGitGadget wrote:
In es/format-patch-rangediff, we added a '--range-diff' option to
git-format-patch to automatically add a range-diff. We also added an option
to write the diff as commentary to a single patch submission. However, this
check
From: Derrick Stolee
The commit 40ce4160 "format-patch: allow --range-diff to apply to
a lone-patch" added the ability to see a range-diff as commentary
after the commit message of a single patch series (i.e. [PATCH]
instead of [PATCH X/N]). However, this functionality was not
covered
...@sunshine.co
Cc: p...@peff.net
[1]
https://github.com/derrickstolee/git/blob/coverage/contrib/coverage-diff.shA
bash script to report uncovered lines that were added in a diff.
Derrick Stolee (1):
t3206-range-diff.sh: cover single-patch case
t/t3206-range-diff.sh | 5 +
1 file changed, 5
On 9/11/2018 12:04 PM, Derrick Stolee wrote:
On 9/11/2018 11:38 AM, Derrick Stolee wrote:
On 9/11/2018 11:25 AM, ryenus wrote:
I just updated to 2.19 via Homebrew, git range-diff seems cool, but I
only got a Segmentation fault: 11
$ git version; git range-diff origin/master HEAD@{2
On 9/11/2018 11:38 AM, Derrick Stolee wrote:
On 9/11/2018 11:25 AM, ryenus wrote:
I just updated to 2.19 via Homebrew, git range-diff seems cool, but I
only got a Segmentation fault: 11
$ git version; git range-diff origin/master HEAD@{2} HEAD
git version 2.19.0
Segmentation
On 9/11/2018 11:25 AM, ryenus wrote:
I just updated to 2.19 via Homebrew, git range-diff seems cool, but I
only got a Segmentation fault: 11
$ git version; git range-diff origin/master HEAD@{2} HEAD
git version 2.19.0
Segmentation fault: 11
Both origin/master and my local
On 9/11/2018 1:22 AM, Christian Couder wrote:
On Wed, Jun 27, 2018 at 3:24 PM, Derrick Stolee wrote:
When writing commit-graph files, it can be convenient to ask for all
reachable commits (starting at the ref set) in the resulting file. This
is particularly helpful when writing to stdin
On 9/7/2018 1:38 PM, Eric Sunshine wrote:
On Fri, Sep 7, 2018 at 11:51 AM Nguyễn Thái Ngọc Duy wrote:
Refreshing the index is usually very fast, but it can still take a
long time sometimes. Cold cache is one, or something else silly (*).
In this case, it's good to show something to let the
On 9/7/2018 1:15 PM, Jeff King wrote:
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
201 - 300 of 1362 matches
Mail list logo
