I recently read the "Supercharging the Git Commit Graph" blog by
Derrick Stolee. I found the article interesting and wanted to verify
the performance numbers for myself. Then that led me to want to know
more about the implementation, so I read the technical design notes in
commit-graph.txt, and
On Wed, Jun 27, 2018 at 07:54:52AM +, Steve Groeger wrote:
> We have common code that is supposed to be usable across different platforms
> and hence different file encodings. With the full support of the
> working-tree-encoding in the latest version of git on all platforms, how do
> we
Use configured comment character when generating comments about branches
in an instruction sheet. Failure to honor this configuration causes a
failure to parse the resulting instruction sheet.
Signed-off-by: Aaron Schrab
---
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
At 12:11 -0700 27 Jun 2018, Junio C Hamano wrote:
Hmph. Do other people have difficulty applying this patch to their
trees? It is just several lines long so I could retype it myself,
but I guess "Content-Type: text/plain; charset=utf-8; format=flowed"
has destroyed formatting of the patch
Jonathan Tan writes:
>> Hmph, don't we quote these in the trace output, requiring us to grep
>> for "'--not' '--all'" or somesuch?
>
> I thought so too, but this was changed in commit 1fbdab21bb ("trace:
> avoid unnecessary quoting", 2018-01-16).
Yup; fortunately or unfortunately, that and
Jonathan Tan writes:
>> Hmph, remind me how old and/or new shallow cut-off points affect
>> this traversal? In order to verify that everything above the new
>> cut-off points, opt->shallow_file should be pointing at the new
>> cut-off points, then we do the full sweep (without --not --all) to
> Jonathan Tan writes:
>
> > +test_expect_success 'shallow fetches check connectivity without stopping
> > at existing refs' '
> > + cp -R .git server.git &&
> > +
> > + # Normally, the connectivity check stops at ancestors of existing refs.
> > + git init client &&
> > +
> Hmph, remind me how old and/or new shallow cut-off points affect
> this traversal? In order to verify that everything above the new
> cut-off points, opt->shallow_file should be pointing at the new
> cut-off points, then we do the full sweep (without --not --all) to
> ensure we won't find
Changes in v6:
* Stricter checks in tests
* Change the name of a test to better reflect what is being tested
* Various style issues fixed in shell scripts
* Renamed one-time-sed.sh to apply-one-time-sed.sh
* Client now errors out when an unexpected ref is sent from the server
during the
Refactor the fetch_refs function into a function that does the fetching
of refs and another function that stores them. This is in preparation
for allowing additional processing of the fetched refs before updating
the local ref store.
Signed-off-by: Brandon Williams
---
builtin/fetch.c | 23
Currently, while performing packfile negotiation, clients are only
allowed to specify their desired objects using object ids. This causes
a vulnerability to failure when an object turns non-existent during
negotiation, which may happen if, for example, the desired repository is
provided by
Add tests to check the behavior of fetching from a repository which
changes between rounds of negotiation (for example, when different
servers in a load-balancing agreement participate in the same stateless
RPC negotiation). This forms a baseline of comparison to the ref-in-want
functionality
Expand the transport fetch method signature, by adding an output
parameter, to allow transports to return information about the refs they
have fetched. Then communicate shallow status information through this
mechanism instead of by modifying the input list of refs.
This does require clients to
Populate peer ref OIDs in get_ref_map instead of do_fetch. Besides
tightening scopes of variables in the code, this also prepares for
get_ref_map being able to be called multiple times within do_fetch.
Signed-off-by: Brandon Williams
---
builtin/fetch.c | 36 ++--
Refactor find_non_local_tags and get_ref_map to only take the
information they need instead of the entire transport struct. Besides
improving code clarity, this also improves their flexibility, allowing
for a different set of refs to be used instead of relying on the ones
stored in the transport
Add an 'unpack-sideband' subcommand to the test-pkt-line helper to
enable unpacking packet line data sent multiplexed using a sideband.
Signed-off-by: Brandon Williams
---
t/helper/test-pkt-line.c | 33 +
1 file changed, 33 insertions(+)
diff --git
Implement ref-in-want on the client side so that when a server supports
the "ref-in-want" feature, a client will send "want-ref" lines for each
reference the client wants to fetch. This feature allows clients to
tolerate inconsistencies that exist when a remote repository's refs
change during the
> +int verify_commit_graph(struct repository *r, struct commit_graph *g)
I haven't had the time to review this patch set, but I did rebase my
object store refactoring [1] on this and wrote a test:
static void test_verify_commit_graph(const char *gitdir, const char
*worktree)
{
On Wed, Jun 27, 2018 at 02:11:13PM -0700, Junio C Hamano wrote:
> Taylor Blau writes:
>
> >> Just initializing match_color where it is defined at the beginning of
> >> show_line() should be sufficient, I think.
> >
> > I think that we could also use the following, and leave the `if
> >
Taylor Blau writes:
>> Just initializing match_color where it is defined at the beginning of
>> show_line() should be sufficient, I think.
>
> I think that we could also use the following, and leave the `if
> (opt->color)` conditional where it is:
>
> diff --git a/grep.c b/grep.c
> index
> Yeah after thinking more about this
I wonder if we have some mental model that we want to teach to the users?
What is the fetch command (using the ref-in-want capability) supposed to do?
* update to the latest state observed by the latest remote talked to?
* update to some approximate state
Junio C Hamano wrote:
> Jeff King writes:
>
>> Specifically, I'm thinking of:
>>
>> 1. The pre-built documentation that Junio builds for
>> quick-install-doc. This _could_ be customized during the "quick"
>> step, but it's probably not worth the effort. However, we'd want
>>
On 06/27, Junio C Hamano wrote:
> Brandon Williams writes:
>
> >> > +* The server SHOULD NOT send any refs which were not requested
> >> > + using 'want-ref' lines and a client MUST ignore refs which
> >> > + weren't requested.
> >>
> >> Just being curious, but the
Jonathan Tan writes:
> +test_expect_success 'shallow fetches check connectivity without stopping at
> existing refs' '
> + cp -R .git server.git &&
> +
> + # Normally, the connectivity check stops at ancestors of existing refs.
> + git init client &&
> + GIT_TRACE="$(pwd)/trace"
Junio C Hamano wrote:
> Todd Zullinger writes:
>
>> The default core.excludesfile path is $XDG_CONFIG_HOME/git/ignore.
>> $HOME/.config/git/ignore is used if XDG_CONFIG_HOME is empty or unset,
>
> ... because $HOME/.config is the default value for XDG_CONFIG_HOME
> when it is unset, that is?
Jonathan Tan writes:
> Do not stop at ancestors of our refs when deepening during fetching.
> This is because when performing such a fetch, shallow entries may have
> been updated; the client can reasonably assume that the existing refs
> are connected up to the old shallow points, but not the
Elijah Newren writes:
> Seems reasonable. Since these tests were essentially copies of other
> tests within the same file, just for rebase -i instead of -m, should I
> also add another patch to the series fixing up the rebase -m testcase
> to also replace the subshell with a single-shot
Johannes Sixt writes:
> Pitfalls ahead!
Thanks. I said "at least the latter" for this exact reason ;-).
> PATH=... git rebase ...
>
> is OK, but
>
> PATH=... test_must_fail git rebase ...
>
> is not; the latter requires the subshell, otherwise the modified PATH
> variable survives
Todd Zullinger writes:
> The default core.excludesfile path is $XDG_CONFIG_HOME/git/ignore.
> $HOME/.config/git/ignore is used if XDG_CONFIG_HOME is empty or unset,
... because $HOME/.config is the default value for XDG_CONFIG_HOME
when it is unset, that is? If so, the change makes sense.
>
Marc Strapetz writes:
> [1. text/plain]
> The current description of "core.ignoreCase" reads like an option which
> is intended to be changed by the user while it's actually expected to
> be set by Git on initialization only. Subsequently, Git relies on the
> proper configuration of this
Brandon Williams writes:
>> > + * The server SHOULD NOT send any refs which were not requested
>> > +using 'want-ref' lines and a client MUST ignore refs which
>> > +weren't requested.
>>
>> Just being curious, but the above feels the other way around. Why
>> are we being more lenient
Sorry for the whitespace bug, it looks like everything is under
control one way or the other.
Johannes Schindelin writes:
> Hi,
>
> On Mon, 25 Jun 2018, Paul-Sebastian Ungureanu wrote:
>
>> This first series of patches does bring some changes and improvements to
>> the test suite. One of the patches also introduces a new function
>> `get_oidf()` which will be hepful for the incoming
Since commit ed8b10f631 ("fsck: check .gitmodules content", 2018-05-02),
fsck will issue an error message for '.gitmodules' content that cannot
be parsed correctly. This is the case, even when the corresponding blob
object has been included on the skiplist. For example, using the cgit
Johannes Schindelin writes:
>> +ret = cmd_checkout(args.argc, args.argv, prefix);
>
> I guess it is okay to run that, but the cmd_() functions are not *really*
> meant to be called this way... Personally, I would be more comfortable
> with a `run_command()` here, i.e. with a spawned process,
On Wed, Jun 27, 2018 at 2:31 PM Stefan Beller wrote:
> From: Eric Sunshine
>
> This test has been dysfunctional since it was added by 259f3ee296
> (lib-submodule-update.sh: define tests for recursing into submodules,
> 2017-03-14), however, problems went unnoticed due to a broken &&-chain
>
> Am 27.06.2018 um 19:27 schrieb Elijah Newren:
> > On Wed, Jun 27, 2018 at 9:54 AM, Junio C Hamano wrote:
> >> Having said that, it would be simpler for at least the latter to
> >> write it using a single-shot environment assignment, perhaps? I.e.
> >>
> >> PATH=./test-bin:$PATH git
From: Eric Sunshine
This test has been dysfunctional since it was added by 259f3ee296
(lib-submodule-update.sh: define tests for recursing into submodules,
2017-03-14), however, problems went unnoticed due to a broken &&-chain
toward the end of the test.
The test wants to verify that replacing
During negotiation, fetch-pack eventually reports as "have" lines all
commits reachable from all refs. Allow the user to restrict the commits
sent in this way by providing a whitelist of tips; only the tips
themselves and their ancestors will be sent.
This feature is only supported for protocols
> diff --git a/t/t3418-rebase-continue.sh b/t/t3418-rebase-continue.sh
> index 03bf1b8a3b..11546d6e14 100755
> --- a/t/t3418-rebase-continue.sh
> +++ b/t/t3418-rebase-continue.sh
> @@ -74,6 +74,38 @@ test_expect_success 'rebase --continue remembers merge
> strategy and options' '
> test -f
On 6/27/2018 2:09 PM, Junio C Hamano wrote:
Derrick Stolee writes:
@@ -40,6 +41,7 @@ static int aggressive_depth = 50;
static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
+static int gc_write_commit_graph = 0;
Please avoid
On Wed, Jun 27, 2018 at 2:17 PM Johannes Sixt wrote:
> Pitfalls ahead!
>
> PATH=... git rebase ...
>
> is OK, but
>
> PATH=... test_must_fail git rebase ...
>
> is not; the latter requires the subshell, otherwise the modified PATH
> variable survives the command because
On 06/27, Jonathan Tan wrote:
> > +test_expect_success 'setup repos for change-while-negotiating test' '
>
> The tests that follow are basic ref-in-want tests, not tests on a repo
> that changes during negotiation - this would be just "setup repos for
> fetch tests".
That looks like a copy-paste
Am 27.06.2018 um 19:27 schrieb Elijah Newren:
On Wed, Jun 27, 2018 at 9:54 AM, Junio C Hamano wrote:
Having said that, it would be simpler for at least the latter to
write it using a single-shot environment assignment, perhaps? I.e.
PATH=./test-bin:$PATH git rebase --continue &&
On 06/26, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Expand the transport fetch method signature, by adding an output
> > parameter, to allow transports to return information about the refs they
> > have fetched. Then communicate shallow status information through this
> > mechanism
Derrick Stolee writes:
> @@ -40,6 +41,7 @@ static int aggressive_depth = 50;
> static int aggressive_window = 250;
> static int gc_auto_threshold = 6700;
> static int gc_auto_pack_limit = 50;
> +static int gc_write_commit_graph = 0;
Please avoid unnecessary (and undesirable) explicit
> +test_expect_success 'setup repos for change-while-negotiating test' '
The tests that follow are basic ref-in-want tests, not tests on a repo
that changes during negotiation - this would be just "setup repos for
fetch tests".
> +test_expect_success 'fetching with exact OID' '
> + rm -rf
Derrick Stolee writes:
> The commit-graph feature is now integrated with 'fsck' and 'gc',
> so remove those items from the "Future Work" section of the
> commit-graph design document.
Nice ;-)
On 06/26, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > diff --git a/t/lib-httpd/one-time-sed.sh b/t/lib-httpd/one-time-sed.sh
> > new file mode 100644
> > index 0..8a9a5aca0
> > --- /dev/null
> > +++ b/t/lib-httpd/one-time-sed.sh
> > @@ -0,0 +1,22 @@
> > +#!/bin/sh
> > +
> > +#
> Brandon Williams writes:
>
> > +wanted-refs section
> > + * This section is only included if the client has requested a
> > + ref using a 'want-ref' line and if a packfile section is also
> > + included in the response.
> > +
> > + * Always begins with the section header
On 06/26, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > +wanted-refs section
> > + * This section is only included if the client has requested a
> > + ref using a 'want-ref' line and if a packfile section is also
> > + included in the response.
> > +
> > + * Always
On Tue, Jun 26, 2018 at 12:30 AM Eric Sunshine wrote:
>
> This test has been dysfunctional since it was added by 619acfc78c
> (submodule add: extend force flag to add existing repos, 2016-10-06),
> however, two problems early in the test went unnoticed due to a broken
> &&-chain later in the
> +# If "one-time-sed" exists in $HTTPD_ROOT_PATH, run sed on the HTTP response,
> +# using the contents of "one-time-sed" as the sed command to be run. If the
> +# response was modified as a result, delete "one-time-sed" so that subsequent
> +# HTTP responses are no longer modified.
> +#
Derrick Stolee writes:
> diff --git a/commit-graph.c b/commit-graph.c
> index a06e7e9549..adf54e3fe7 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -7,6 +7,7 @@
> #include "packfile.h"
> #include "commit.h"
> #include "object.h"
> +#include "refs.h"
> #include "revision.h"
>
Derrick Stolee writes:
> + devnull = open("/dev/null", O_WRONLY);
> + f = hashfd(devnull, NULL);
> + hashwrite(f, g->data, g->data_len - g->hash_len);
I wondered if we can hide the knowledge of "/dev/null" by reusing
hashfd_check() from csum-file.c (which is used by the verification
On 27.06.18 09:54, Steve Groeger wrote:
> Hi,
>
> Sorry for incomplete post earlier. Here is the full post:
>
>
> In the latest version of git a new attribute has been added,
> working-tree-encoding. The release notes states:
>
> 'The new "working-tree-encoding" attribute can ask Git to
Derrick Stolee writes:
> The commit-graph tests should be checking that normal Git operations
> succeed and have matching output with and without the commit-graph
> feature enabled. However, the test was toggling 'core.graph' instead
> of the correct 'core.commitGraph' variable.
>
>
Do not stop at ancestors of our refs when deepening during fetching.
This is because when performing such a fetch, shallow entries may have
been updated; the client can reasonably assume that the existing refs
are connected up to the old shallow points, but not the new.
This was noticed when a
On Wed, Jun 27, 2018 at 9:54 AM, Junio C Hamano wrote:
> + (
> + PATH=./test-bin:$PATH
> + test_must_fail git rebase -i -s funny -Xopt -Xfoo master topic
> + ) &&
>
> + (
> + PATH=./test-bin:$PATH
> + git rebase --continue
On Wed, Jun 27, 2018 at 09:40:10AM -0700, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > - if (sign == ':')
> > - match_color = opt->color_match_selected;
> > - else
> > - match_color = opt->color_match_context;
> > - if (sign
On Mon, Jun 25, 2018 at 8:58 AM Junio C Hamano wrote:
>
> SZEDER Gábor writes:
>
> >> When an error occurs in updating the working tree of a submodule in
> >> submodule_move_head, tell the user which submodule the error occurred in.
> >>
> >> The call to read-tree contains a super-prefix, such
Elijah Newren writes:
>>> + chmod +x test-bin/git-merge-funny &&
>>> + (
>>> + PATH=./test-bin:$PATH
>>
>> Broken &&-chain (in subshell).
>>
>>> + test_must_fail git rebase -i -s funny -Xopt -Xfoo master
>>> topic
>>> + ) &&
>>> + test -f
Jeff King writes:
> Specifically, I'm thinking of:
>
> 1. The pre-built documentation that Junio builds for
> quick-install-doc. This _could_ be customized during the "quick"
> step, but it's probably not worth the effort. However, we'd want
> some kind of generic fill-in then,
I wrote:
> Jeff King wrote:
>> (Related, there's a build target in the local Makefile for using
>> asciidoctor; does it need updated, too?)
>
> I didn't test asciidoctor specficially, but it also respects
> the ASCIIDOC_EXTRA parameters, so I think it will work just
> as well. I'll try
Taylor Blau writes:
> - if (sign == ':')
> - match_color = opt->color_match_selected;
> - else
> - match_color = opt->color_match_context;
> - if (sign == ':')
> - line_color = opt->color_selected;
>
Johannes Schindelin writes:
> git rev-list --bisect-all --first-parent F..E >revs &&
> # only E, e1..e8 should be listed, nothing else
> test_line_count = 9 revs &&
> for rev in E e1 e2 e3 e4 e5 e6 e7 e8
> do
> grep "^$(git rev-parse $rev) " revs ||
The interactive machinery for git rebase can accept special merge
strategies or strategy options, but has a bug in its handling of
strategy options. This short series patches that.
Changes since v2:
- Fix broken &&-chaining (Thanks to Eric for spotting)
Elijah Newren (2):
t3418: add
git-rebase.sh wrote strategy options to .git/rebase/merge/strategy_opts
in the following format:
'--ours' '--renormalize'
Note the double spaces.
git-rebase--interactive uses sequencer.c to parse that file, and
sequencer.c used split_cmdline() to get the individual strategy options.
After
We are not passing the same args to merge strategies when we are doing an
--interactive rebase as we do with a --merge rebase. The merge strategy
should not need to be aware of which type of rebase is in effect. Add a
testcase which checks for the appropriate args.
Signed-off-by: Elijah Newren
Jeff King wrote:
> On Wed, Jun 27, 2018 at 12:56:37AM -0400, Todd Zullinger wrote:
>
>> Replace `$(prefix)/etc/gitconfig` and `$(prefix)/etc/gitattributes` in
>> generated documentation with the paths chosen when building. Readers of
>> the documentation should not need to know how `$(prefix)`
Hi Johannes,
Le 26/06/2018 à 23:37, Johannes Schindelin a écrit :
> Hi Alban,
>
> On Tue, 26 Jun 2018, Alban Gruin wrote:
>
>> This patch rewrites append_todo_help() from shell to C. The C version
>> covers a bit more than the old shell version. To achieve that, some
>> parameters were added to
Hi Johannes,
Le 26/06/2018 à 23:41, Johannes Schindelin a écrit :
> Hi Alban,
>
> On Tue, 26 Jun 2018, Alban Gruin wrote:
>
>> diff --git a/sequencer.h b/sequencer.h
>> index c5787c6b5..08397b0d1 100644
>> --- a/sequencer.h
>> +++ b/sequencer.h
>> @@ -3,6 +3,7 @@
>>
>> const char
On Wed, Jun 27, 2018 at 12:56:37AM -0400, Todd Zullinger wrote:
> Replace `$(prefix)/etc/gitconfig` and `$(prefix)/etc/gitattributes` in
> generated documentation with the paths chosen when building. Readers of
> the documentation should not need to know how `$(prefix)` was defined.
Yes, I was
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 is complicated, such as a
future integration with 'git gc'.
Signed-off-by: Derrick Stolee
---
Signed-off-by: Derrick Stolee
---
builtin/commit-graph.c | 39 +--
commit-graph.c | 15 +++
commit-graph.h | 7 +++
3 files changed, 23 insertions(+), 38 deletions(-)
diff --git a/builtin/commit-graph.c
The commit-graph file requires the following three chunks:
* OID Fanout
* OID Lookup
* Commit Data
If any of these are missing, then the 'verify' subcommand should
report a failure. This includes the chunk IDs malformed or the
chunk count is truncated.
Signed-off-by: Derrick Stolee
---
If core.commitGraph is true, verify the contents of the commit-graph
during 'git fsck' using the 'git commit-graph verify' subcommand. Run
this check on all alternates, as well.
We use a new process for two reasons:
1. The subcommand decouples the details of loading and verifying a
The commit-graph file ends with a SHA1 hash of the previous contents. If
a commit-graph file has errors but the checksum hash is correct, then we
know that the problem is a bug in Git and not simply file corruption
after-the-fact.
Compute the checksum right away so it is the first error that
In the 'verify' subcommand, load commits directly from the object
database to ensure they exist. Parse by skipping the commit-graph.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 18 ++
t/t5318-commit-graph.sh | 7 +++
2 files changed, 25 insertions(+)
diff
The commit-graph feature is now integrated with 'fsck' and 'gc',
so remove those items from the "Future Work" section of the
commit-graph design document.
Also remove the section on lazy-loading trees, as that was completed
in an earlier patch series.
Signed-off-by: Derrick Stolee
---
Signed-off-by: Derrick Stolee
---
commit-graph.c | 6 ++
t/t5318-commit-graph.sh | 6 ++
2 files changed, 12 insertions(+)
diff --git a/commit-graph.c b/commit-graph.c
index e0f71658da..6d6c6beff9 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -986,6 +986,12 @@ int
The commit-graph file is a very helpful feature for speeding up git
operations. In order to make it more useful, make it possible to
write the commit-graph file during standard garbage collection
operations.
Add a 'gc.commitGraph' config setting that triggers writing a
commit-graph file after any
In the commit-graph file, the OID fanout chunk provides an index into
the OID lookup. The 'verify' subcommand should find incorrect values
in the fanout.
Similarly, the 'verify' subcommand should find out-of-order values in
the OID lookup.
Signed-off-by: Derrick Stolee
---
commit-graph.c
The 'verify' subcommand must compare the commit content parsed from the
commit-graph against the content in the object database. Use
lookup_commit() and parse_commit_in_graph_one() to parse the commits
from the graph and compare against a commit that is loaded separately
and parsed directly from
While iterating through the commit parents, perform the generation
number calculation and compare against the value stored in the
commit-graph.
The tests demonstrate that having a different set of parents affects
the generation number calculation, and this value propagates to
descendants. Hence,
The commit-graph file stores parents in a two-column portion of the
commit data chunk. If there is only one parent, then the second column
stores 0x to indicate no second parent.
The 'verify' subcommand checks the parent list for the commit loaded
from the commit-graph and the one parsed
The commit-graph file has an extra chunk to store the parent int-ids for
parents beyond the first parent for octopus merges. Our test repo has a
single octopus merge that we can manipulate to demonstrate the 'verify'
subcommand detects incorrect values in that chunk.
Signed-off-by: Derrick Stolee
Before verifying a commit-graph file against the object database, we
need to parse all commits from the given commit-graph file. Create
parse_commit_in_graph_one() to target a given struct commit_graph.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 18 +++---
1 file changed, 15
If the commit-graph file becomes corrupt, we need a way to verify
that its contents match the object database. In the manner of
'git fsck' we will implement a 'git commit-graph verify' subcommand
to report all issues with the file.
Add the 'verify' subcommand to the 'commit-graph' builtin and its
From: Derrick Stolee
This v7 has very little material difference from the previous version.
The only changes are:
* Rename 'gc.commitGraph' to 'gc.writeCommitGraph'
* Add 't5318-commit-graph.sh: use core.commitGraph' patch that was
dropped.
* Rebase onto latest master, which appears to fix
In anticipation of verifying commit-graph file contents against the
object database, create parse_commit_internal() to allow side-stepping
the commit-graph file and parse directly from the object database.
Due to the use of generation numbers, this method should not be called
unless the intention
This is the first of several commits that add a test to check that
'git commit-graph verify' catches corruption in the commit-graph
file. The first test checks that the command catches an error in
the file signature. This is a check that exists in the existing
commit-graph reading code.
Add a
The commit-graph tests should be checking that normal Git operations
succeed and have matching output with and without the commit-graph
feature enabled. However, the test was toggling 'core.graph' instead
of the correct 'core.commitGraph' variable.
Signed-off-by: Derrick Stolee
---
Junio,
I
When lazy-loading a tree for a commit, it will be important to select
the tree from a specific struct commit_graph. Create a new method that
specifies the commit-graph file and use that in
get_commit_tree_in_graph().
Signed-off-by: Derrick Stolee
---
commit-graph.c | 12 +---
1 file
Signed-off-by: Derrick Stolee
---
builtin/commit-graph.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
index 37420ae0fd..f0875b8bf3 100644
--- a/builtin/commit-graph.c
+++ b/builtin/commit-graph.c
@@ -51,8 +51,11 @@ static
The GRAPH_MIN_SIZE macro should be the smallest size of a parsable
commit-graph file. However, the minimum number of chunks was wrong.
It is possible to write a commit-graph file with zero commits, and
that violates this macro's value.
Rewrite the macro, and use extra macros to better explain the
Hi Vlad,
On Wed, 27 Jun 2018, Vladimir Parfinenko wrote:
> Last sections are squashed into non-formatted block after adding
> "REBASING MERGES".
> To reproduce the error see bottom of page:
> https://git-scm.com/docs/git-rebase
>
> Signed-off-by: Vladimir Parfinenko
ACK!
Thank you so much
Hi Junio,
On Tue, 26 Jun 2018, Junio C Hamano wrote:
> Christian Couder writes:
>
> > Obviousness is often not the same for everybody.
>
> ... which you just learned---what you thought obvious turns out to
> be not so obvious after all, so you adjust to help your readers.
Indeed. And trying
Hi Dana,
On Tue, 26 Jun 2018, dana wrote:
> On 26 Jun 2018, at 16:44, Johannes Schindelin
> wrote:
> >There is of course one other way to fix this, and that is by rewriting
> >this in C.
> >
> >Which Alban has done here ;-)
> >
>
Last sections are squashed into non-formatted block after adding
"REBASING MERGES".
To reproduce the error see bottom of page:
https://git-scm.com/docs/git-rebase
Signed-off-by: Vladimir Parfinenko
---
Documentation/git-rebase.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
1 - 100 of 121 matches
Mail list logo
