"Derrick Stolee via GitGitGadget" writes:
> * revs->limited implies we run limit_list() to walk the entire
> reachable set. There are some short-cuts here, such as if we
> perform a range query like 'git rev-list COMPARE..HEAD' and we
> can stop limit_list() when all queued commits are unin
SZEDER Gábor writes:
>> for (i = 0; i < oids->nr; i++) {
>> +display_progress(progress, ++j);
>> commit = lookup_commit(the_repository, &oids->list[i]);
>>
>> if (commit && !parse_commit(commit))
>> @@ -611,19 +624,28 @@ static void close_reachable(str
The previous git-p4 unshelve support would check for changes
in Perforce to the files being unshelved since the original
shelve, and would complain if any were found.
This was to ensure that the user wouldn't end up with both the
shelved change delta, and some deltas from other changes in their
gi
This patch series teaches the git-p4 unshelve command to handle
intervening changes to the Perforce files.
At the moment if you try to unshelve a file, and that file has been
modified since the shelving, git-p4 refuses. That is so that it
doesn't end up generating a commit containing deltas from s
If deleting or moving a file, sometimes P4 doesn't report the file size.
The code handles this just fine but some logging crashes. Stop this
happening.
There was some earlier discussion on the list about this:
https://public-inbox.org/git/xmqq1sqpp1vv@gitster.mtv.corp.google.com/
Signed-off
The branch detection code looks for branches under refs/remotes/p4/...
and can end up getting confused if there are unshelved changes in
there as well. This happens in the function p4BranchesInGit().
Instead, put the unshelved changes into refs/remotes/p4-unshelved/.
Signed-off-by: Luke Diamand
Jeff King writes:
> On Fri, Sep 21, 2018 at 10:39:30AM -0700, Derrick Stolee via GitGitGadget
> wrote:
>
>> 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
I'll do the s/octu/octo/; again on the title while queuing.
Let's merge this to 'next'.
Thanks.
Ævar Arnfjörð Bjarmason writes:
> On Thu, Oct 11 2018, SZEDER Gábor wrote:
>
>> Fourth and hopefully final round of fixing occasional test failures when
>> run with 'GIT_TEST_SPLIT_INDEX=yes'. The only code change is the
>> extraction of a helper function to compare two cache entries' content,
>
Ben Peart writes:
> From: Ben Peart
>
> Fixed issues identified in review the most impactful probably being plugging
> some leaks and improved error handling. Also added better error messages
> and some code cleanup to code I'd touched.
>
> The biggest change in the interdiff is the impact of r
Rasmus Villemoes writes:
> v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
> config option, no delay) redirect to the aliased command's help,
> preserve pre-existing behaviour of the spelling "git help cmd".
>
> v3: Add some additional comments in patch 1 and avoid triggering
"Derrick Stolee via GitGitGadget" writes:
> CHANGES IN V4: I reduced the blame output using -s which decreases the
> width. I include a summary of the commit authors at the end to help people
> see the lines they wrote. This version is also copied into a build
> definition in the public Git proje
Junio C Hamano writes:
> Olga Telezhnaya writes:
These three patches seem to cause t6300 to fail with an attempt to
free an invalid pointer in "git for-each-ref --format='%(push)'"
(6300.25)
*** Error in `/home/gitster/w/git.git/git': free(): invalid pointer:
0x55cca3a9f920 ***
=== B
Dear International Sales & Marketing Director
Zhejiang Wuchuan Industrial Co., Ltd,
This is Reed Exhibitions Japan Ltd., organiser of MARKETING & SALES PROMOTION
EXPO [June].
MARKETING & SALES PROMOTION EXPO [June] is Japan's largest trade show for
marketing & sales promotion products and solut
Stefan Beller writes:
> Noticed-by: Junio C Hamano
> Signed-off-by: Stefan Beller
> ---
>
>
>There is no "ignore-any" supported by the feature---I think that
>the parser for the option should have noticed and barfed, but it
>did not. It merely emitted a message to the standard out
From: Josh Steadmon
This is an alternate approach to the previous series. We add a registry
of supported wire protocol versions that individual commands can use to
declare supported versions before contacting a server. The client will
then advertise all supported versions, while the server will c
From: Josh Steadmon
Currently the client advertises that it supports the wire protocol
version set in the protocol.version config. However, not all services
support the same set of protocol versions. When connecting to
git-receive-pack, the client automatically downgrades to v0 if
config.protocol
Stefan Beller writes:
> I think we should add these tweaks, such that
> color-moved-ws implies color-moved (both config and CLI options)
> and --color-moved implies --color (command line only)
I am not sure what you mean by "both config and". I'd find it
entirely sensible for a user to say "I d
On Tue, 9 Oct 2018 at 21:43, Junio C Hamano wrote:
> I had a bit hard time parsing the above, especially with "then",
> which probably would make it easier to read if it is not there.
Okay, I guess better to separate the explanation from the diagrams,
rather than weaving them together:
For
Stefan Beller writes:
> Additionally each patch adds a semantic patch, that would port from the old to
> the new function. These semantic patches are all applied in the very last
> patch,
> but we could omit applying the last patch if it causes too many merge
> conflicts
> and trickl in the sem
On 10/12/18 1:15 AM, Junio C Hamano wrote:
> It is a bit curious why you remove the branch but not the tag after
> this test. [..]
>
> So two equally valid choices are to remove "branch -d" and then
> either:
>
> (1) leave both branch and tag after this test in the test
> repository
>
>
Daniels Umanovskis writes:
> +static void print_current_branch_name(void)
Thanks for fixing this (I fixed this in the previous round in my
tree but forgot to tell you about it).
> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
> index ee6787614..8d2020aea 100755
> --- a/t/t320
> Do you know if pushing of submodules is exercised by any test?
t5531-deep-submodule-push.sh (all of them)
t5545-push-options.sh (ok 4 - push options and submodules)
Implement positive values for in the tree: filter. The
exact semantics are described in Documentation/rev-list-options.txt.
The long-term goal at the end of this is to allow a partial clone to
eagerly fetch an entire directory of files by fetching a tree and
specifying =1. This, for instance, wou
git-rev-list has a mode where it works on the granularity of trees and
blobs, rather than commits only. When discussing this mode in
documenation, it can get awkward to refer to the list of arguments that
may include blobs and trees as . It is especially awkward in a
follow-up patch, so prepare for
The tree:0 filter does not need to traverse the trees that it has
filtered out, so optimize list-objects and list-objects-filter to skip
traversing the trees entirely. Before this patch, we iterated over all
children of the tree, and did nothing for all of them, which was
wasteful.
Signed-off-by:
This adds support for depth >0 in the tree: filter. Before this patch,
only =0 is supported, which means all trees and blobs are filtered.
The purpose of this is to allow fetching of entire directories in a partial
clone use case. If I do a partial clone of a repo with no objects and then want
to
> This series takes another approach as it doesn't change the signature of
> functions, but introduces new functions that can deal with arbitrary
> repositories, keeping the old function signature around using a shallow
> wrapper.
>
> Additionally each patch adds a semantic patch, that would por
On Thu, Oct 11, 2018 at 3:41 PM Junio C Hamano wrote:
> * After fixing ignore-any to one of the supported option
>(e.g. "ignore-all-spaces"), the color-moved feature still did not
>trigger. I think the presence of --color-moved-ws by itself is a
>hint that the user wants --color-mov
On Thu, Oct 11, 2018 at 3:59 PM Stefan Beller wrote:
> - error(_("ignoring unknown color-moved-ws mode '%s'"),
> sb.buf);
> + die(_("ignoring unknown color-moved-ws mode '%s'"),
> sb.buf);
s/ignoring// as it was sent in a haste.
> The submodule was added as an alternative in eb21c732d6 (push: teach
> --recurse-submodules the on-demand option, 2012-03-29), but was
> not explained, why.
>
> In similar code, submodule_has_commits, the submodule is added as an
> alternative to perform a quick check if we need to dive into the
Noticed-by: Junio C Hamano
Signed-off-by: Stefan Beller
---
There is no "ignore-any" supported by the feature---I think that
the parser for the option should have noticed and barfed, but it
did not. It merely emitted a message to the standard output and
let it scroll away with the
On 10/12/18 12:56 AM, SZEDER Gábor wrote:
> Ah, OK, just noticed v3 which has already fixed this.
>
Yeah - squashed the wrong commits locally for v2. Thanks for pointing
this out anyway!
On Fri, Oct 12, 2018 at 12:53:26AM +0200, SZEDER Gábor wrote:
> On Wed, Oct 10, 2018 at 10:54:32PM +0200, Daniels Umanovskis wrote:
>
> [...]
>
> > diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
> > index ee6787614..e9bc3b05f 100755
> > --- a/t/t3203-branch-output.sh
> > +++ b/t
On Wed, Oct 10, 2018 at 10:54:32PM +0200, Daniels Umanovskis wrote:
[...]
> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
> index ee6787614..e9bc3b05f 100755
> --- a/t/t3203-branch-output.sh
> +++ b/t/t3203-branch-output.sh
> @@ -100,6 +100,47 @@ test_expect_success 'git branch
Ævar Arnfjörð Bjarmason writes:
> On Wed, Oct 10 2018, Jeff King wrote:
>
>> This is much better, and I love the customized behavior based on the
>> object type.
>>
>> I wonder if we could reword the first paragraph to be a little less
>> confusing, and spell out what we tried already. E.g., some
> +/*
> + * Initialize 'out' based on the provided submodule path.
> + *
> + * Unlike repo_submodule_init, this tolerates submodules not present
> + * in .gitmodules. NEEDSWORK: The repo_submodule_init behavior is
> + * preferrable. This function exists only to preserve historical behavior.
What d
Phillip Wood writes:
> On 10/10/2018 06:43, Junio C Hamano wrote:
>> Here are the topics that have been cooking. Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'. The ones marked with '.' do not appear in any of
>> the integration
Hello my dear.
Did you receive my email message to you? Please, get back to me ASAP as the
matter is becoming late. Expecting your urgent response.
Sean.
On Thu, Oct 11, 2018 at 04:53:23PM -0400, Jeff King wrote:
> Right, I like that part. It's just that putting "HEAD" there already has
> a meaning: it would find refs/heads/HEAD.
>
> Now I'll grant that's a bad name for a branch (and the source of other
> confusions, and I think perhaps even someth
On Fri, Sep 21, 2018 at 10:39 AM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
[...]
> For the test above, I specifically selected a path that is changed
> frequently, including by merge commits. A less-frequently-changed
> path (such as 'README') has similar end-to-end time sin
Patches 6-16 are all quite straightforward, and are reviewed-by: me.
When called with --show-current, git branch will print the current
branch name and terminate. Only the actual name gets printed,
without refs/heads. In detached HEAD state, nothing is output.
Intended both for scripting and interactive/informative use.
Unlike git branch --list, no filtering is nee
> In 8e4b0b6047 (object.c: allow parse_object to handle
> arbitrary repositories, 2018-06-28), we forgot to pass the
> repository down to the read_object_file.
[snip]
> @@ -270,7 +270,7 @@ struct object *parse_object(struct repository *r, const
> struct object_id *oid)
> return loo
On Thu, Oct 11, 2018 at 3:01 PM Jonathan Tan wrote:
>
> > Introduce repo_read_object_file which takes the repository argument, and
> > hide the original read_object_file as a macro behind
> > NO_THE_REPOSITORY_COMPATIBILITY_MACROS, which we planned for in
> > e675765235 (diff.c: remove implicit de
> Introduce repo_read_object_file which takes the repository argument, and
> hide the original read_object_file as a macro behind
> NO_THE_REPOSITORY_COMPATIBILITY_MACROS, which we planned for in
> e675765235 (diff.c: remove implicit dependency on the_index, 2018-09-21)
That commit didn't seem to
> @@ -1413,10 +1414,10 @@ void *read_object_file_extended(const struct
> object_id *oid,
> const char *path;
> struct stat st;
> const struct object_id *repl = lookup_replace ?
> - lookup_replace_object(the_repository, oid) : oid;
> + lookup_replace_object
Previous commits added some cocci rules, but did not patch the whole tree,
as to not dilute the focus for reviewing the previous patches.
This patch is generated by 'make coccicheck' and applying the resulting
diff, which was white space damaged (>8 spaces after a tab) in blame.c,
which has been f
Signed-off-by: Stefan Beller
---
commit.c| 15 +--
commit.h| 8 ++--
contrib/coccinelle/the_repository.cocci | 17 +
3 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/commit.c b/commit.c
Signed-off-by: Stefan Beller
---
commit.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/commit.c b/commit.c
index 5e8791f0c1..f8a8844a72 100644
--- a/commit.c
+++ b/commit.c
@@ -995,7 +995,7 @@ struct commit_list *get_octopus_merge_bases(struct
commit_list *in)
This converts the 'show_submodule_header' function to use
the repository API properly, such that the submodule objects
are not added to the main object store.
Signed-off-by: Stefan Beller
---
submodule.c | 48 ++--
1 file changed, 38 insertions(+), 10
Signed-off-by: Stefan Beller
---
contrib/coccinelle/the_repository.cocci | 10 ++
pretty.c| 15 ---
pretty.h| 7 ++-
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/contrib/coccinelle/the_repo
Signed-off-by: Stefan Beller
---
commit.c| 6 --
commit.h| 7 ++-
contrib/coccinelle/the_repository.cocci | 8
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/commit.c b/commit.c
index eca9a475c7..526
Signed-off-by: Stefan Beller
---
commit.h| 8
contrib/coccinelle/the_repository.cocci | 9 +
pretty.c| 13 +++--
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/commit.h b/commit.h
index 097
The submodule was added as an alternative in eb21c732d6 (push: teach
--recurse-submodules the on-demand option, 2012-03-29), but was
not explained, why.
In similar code, submodule_has_commits, the submodule is added as an
alternative to perform a quick check if we need to dive into the submodule.
Just like the previous commit, parse_commit and friends are used a lot
and are found in new patches, so we cannot change their signature easily.
Re-introduce these function prefixed with 'repo_' that take a repository
argument and keep the original as a shallow macro.
Signed-off-by: Stefan Beller
Signed-off-by: Stefan Beller
---
commit.c| 8 +---
commit.h| 7 ++-
contrib/coccinelle/the_repository.cocci | 7 +++
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/commit.c b/commit.c
index 2733bef019..31
Signed-off-by: Stefan Beller
---
commit.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/commit.c b/commit.c
index f8a8844a72..b36c2aa0bf 100644
--- a/commit.c
+++ b/commit.c
@@ -1055,7 +1055,8 @@ static int remove_redundant(struct repository *r, struct
commit
has_packed_and_bad is not widely used, so just migrate it all at once.
Signed-off-by: Stefan Beller
---
packfile.c | 5 +++--
packfile.h | 2 +-
sha1-file.c | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/packfile.c b/packfile.c
index ebcb5742ec..40085fe160 100644
--- a/
Signed-off-by: Stefan Beller
---
commit.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/commit.c b/commit.c
index f493a82f72..5e8791f0c1 100644
--- a/commit.c
+++ b/commit.c
@@ -934,7 +934,9 @@ static struct commit_list *paint_down_to_common(struct
repository *
Similarly to previous patches, the get_merge_base functions are used
often in the code base, which makes migrating them hard.
Implement the new functions, prefixed with 'repo_' and hide the old
functions behind a wrapper macro.
Signed-off-by: Stefan Beller
---
commit.c
As the function is file local and not widely used, migrate it all at once.
Signed-off-by: Stefan Beller
---
commit.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/commit.c b/commit.c
index c6aeedc3d8..f493a82f72 100644
--- a/commit.c
+++ b/commit.c
@@ -869,7
In 8e4b0b6047 (object.c: allow parse_object to handle
arbitrary repositories, 2018-06-28), we forgot to pass the
repository down to the read_object_file.
Signed-off-by: Stefan Beller
---
object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/object.c b/object.c
index 51c459
This applies on nd/the-index (b3c7eef9b05) and is the logical continuation of
the object store series, which I sent over the last year.
The previous series did take a very slow and pedantic approach,
using a #define trick, see cfc62fc98c for details, but it turns out,
that it doesn't work:
When
read_object_file_extended is not widely used, so migrate it all at once.
Signed-off-by: Stefan Beller
---
object-store.h | 5 +++--
sha1-file.c| 11 ++-
streaming.c| 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/object-store.h b/object-store.h
index 67e6
As read_object_file is a widely used function (which is also regularly used
in new code in flight between master..pu), changing its signature is painful
is hard, as other series in flight rely on the original signature. It would
burden the maintainer if we'd just change the signature.
Introduce re
Allow read_object (a file local functon in sha1_file) to
handle arbitrary repositories by passing the repository down
to oid_object_info_extended.
Signed-off-by: Stefan Beller
---
sha1-file.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/sha1-file.c b/sha1-file.c
On Thu, Oct 11, 2018 at 09:35:28PM +0100, Rafael Ascensão wrote:
> On Thu, Oct 11, 2018 at 01:51:36PM -0400, Jeff King wrote:
> > Yeah, I agree.
>
> Not sure which parts you meant, so I'll assume you didn't agree
> with me.
Correct. ;)
I like your general idea, but I agree with Daniel that it i
On 10/11/18 10:35 PM, Rafael Ascensão wrote:
> The output of the proposed command is also a bit inconsistent with the
> usual output given by git branch, specifically the space alignment on
> the left, color and * marker.
The proposed command therefore takes a new switch. It's definitely not
perfe
On Thu, Oct 11, 2018 at 06:36:02PM +0200, Daniels Umanovskis wrote:
> I am not a fan because it would be yet another inconsistency in the Git
> command interface.
The output of the proposed command is also a bit inconsistent with the
usual output given by git branch, specifically the space alignme
From: "Strain, Roger L"
Adds recursive evaluation of parent commits which were not part of the
initial commit list when performing a split.
Split expects all relevant commits to be reachable from the target commit
but not reachable from any previous rejoins. However, a branch could be
based on a
After doing some testing at scale, determined that one call was taking too
long; replaced that with an alternate call which returns the same data
significantly faster.
Also, if anyone has any other feedback on these I'd really love to hear it.
It's working better for us (as in, it actually gene
From: "Strain, Roger L"
In a particularly complex repo, subtree split was not creating
compatible splits for pushing back to a separate repo. Addressing
one of the issues requires recursive handling of parent commits
that were not initially considered by the algorithm. This commit
makes no functi
From: "Strain, Roger L"
Changes the behavior of --ignore-joins to always consider a subtree add
commit, and ignore only splits and squashes.
The --ignore-joins option is documented to ignore prior --rejoin commits.
However, it additionally ignored subtree add commits generated when a
subtree was
From: "Strain, Roger L"
When multiple identical parents are detected for a commit being considered
for copying, explicitly check whether one is the common merge base between
the commits. If so, the other commit can be used as the identical parent;
if not, a merge must be performed to maintain his
Le 11/10/2018 à 17:16, Phillip Wood a écrit :
> On 07/10/2018 20:54, Alban Gruin wrote:
>> Just like complete_action(), edit_todo_list() used a
>> function (transform_todo_file()) that read the todo-list from the disk
>> and wrote it back, resulting in useless disk accesses.
>>
>> This changes edit
Signed-off-by: Jonathan Tan
---
> One main benefit of storing on Bloom filter per commit is to avoid
> recomputing hashes at every commit. Currently, this patch only improves
> locality when checking membership at the cost of taking up more space.
> Drop the dependence on the parent oid and then w
This is definitely a low-level command, it's hard to argue
against it belonging in plumbing.
Signed-off-by: Daniels Umanovskis
---
command-list.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/command-list.txt b/command-list.txt
index c36ea3c18..966705358 100644
--- a/comm
Also remove git-cherry from Bash completion because plumbing
commands do not belong there.
Signed-off-by: Daniels Umanovskis
---
Up to discussion whether cherry should be considered plumbing.
I lean towards considering it a rarely-used porcelain command, but
a case could be made either way so le
On Wed, Oct 10 2018, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Oct 10 2018, SZEDER Gábor wrote:
>
>> On Wed, Oct 10, 2018 at 11:56:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>> On Wed, Oct 10 2018, SZEDER Gábor wrote:
>>
>>> >> for (i = 0; i < oids->nr; i++) {
>>> >> +di
On Thu, Oct 11, 2018 at 07:29:58PM +0200, Daniels Umanovskis wrote:
> > Without passing the &flag argument, I do not think there is a
> > reliable way to ask resolve_ref_unsafe() if "HEAD" is a symbolic
> > ref.
>
> If I'm reading the code correctly, resolve_ref_unsafe() will return
> "HEAD" or N
On Thu, Oct 11, 2018 at 06:36:02PM +0200, Daniels Umanovskis wrote:
> On 10/11/18 5:43 PM, Rafael Ascensão wrote:
> > I agree it feels a bit out of place, and still think that
> >
> > $ git branch --list HEAD
> >
> > would be a good candidate to be taught how to print the current branch.
>
On 10/11/18 8:54 AM, Junio C Hamano wrote:
> Is it a normal situation to have refname==NULL, or is it something
> worth reporting as an error?
Looks like that would be in the case of looping symrefs or file backend
failure, so seems a good idea to die() in that case.
> Without passing the &flag a
Le 11/10/2018 à 15:51, Phillip Wood a écrit :
> On 07/10/2018 20:54, Alban Gruin wrote:
>> + if (rewrite_file(todo_file, new_todo.buf.buf, new_todo.buf.len) <
>> 0) {
>> + todo_list_release(&new_todo);
>> + return error_errno(_("could not write '%s'"), todo_file);
>> + }
>
> re
Hi Phillip,
thanks for taking the time to review my patches.
Le 11/10/2018 à 13:25, Phillip Wood a écrit :
> On 07/10/2018 20:54, Alban Gruin wrote:
>> @@ -4419,15 +4406,38 @@ int sequencer_add_exec_commands(const char
>> *commands)
>> }
>> /* insert or append final */
>> - if (
On 10/11/18 5:43 PM, Rafael Ascensão wrote:
> I agree it feels a bit out of place, and still think that
>
> $ git branch --list HEAD
>
> would be a good candidate to be taught how to print the current branch.
I am not a fan because it would be yet another inconsistency in the Git
command int
On 10/11/2018 11:35 AM, Jeff King wrote:
On Fri, Sep 21, 2018 at 10:39:36AM -0700, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
When running a command like 'git rev-list --topo-order HEAD',
Git performed the following steps:
[...]
In the new algorithm, these three steps corresp
On Wed, Oct 10, 2018 at 08:34:40PM -0400, Jeff King wrote:
> It just seems like in its current form it might be in an uncanny valley
> where it is not quite scriptable plumbing, but not as informative as
> other porcelain.
I agree it feels a bit out of place, and still think that
$ git branch
On Fri, Sep 21, 2018 at 10:39:36AM -0700, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> When running a command like 'git rev-list --topo-order HEAD',
> Git performed the following steps:
> [...]
> In the new algorithm, these three steps correspond to three
> different commit
On 07/10/2018 20:54, Alban Gruin wrote:
Just like complete_action(), edit_todo_list() used a
function (transform_todo_file()) that read the todo-list from the disk
and wrote it back, resulting in useless disk accesses.
This changes edit_todo_list() to call directly todo_list_transform()
instead.
On Fri, Sep 21, 2018 at 10:39:33AM -0700, Derrick Stolee via GitGitGadget wrote:
> 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_
On Fri, Sep 21, 2018 at 10:39:32AM -0700, Derrick Stolee via GitGitGadget wrote:
> [..]
> When setting revs->limited only because revs->topo_order is true,
> only do so if generation numbers are not available. There is no
> reason to use the new logic as it will behave similarly when all
> generat
On Fri, Sep 21, 2018 at 10:39:30AM -0700, Derrick Stolee via GitGitGadget wrote:
> 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 re
On Fri, Sep 21, 2018 at 10:39:29AM -0700, Derrick Stolee via GitGitGadget wrote:
> 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 co
On Fri, Sep 21, 2018 at 10:39:27AM -0700, 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' o
On 07/10/2018 20:54, Alban Gruin wrote:
complete_action() used functions that read the todo-list file, made some
changes to it, and wrote it back to the disk.
The previous commits were dedicated to separate the part that deals with
the file from the actual logic of these functions. Now that thi
On Thu, Oct 11, 2018 at 08:33:58AM -0400, Derrick Stolee wrote:
> > I don't know if this is a fruitful path at all or not. I was mostly just
> > satisfying my own curiosity on the bitmap encoding question. But I'll
> > post the patches, just to show my work. The first one is the same
> > initial p
On 10/10/2018 9:21 PM, Jonathan Tan wrote:
diff --git a/commit-graph.c b/commit-graph.c
index f415d3b41f..90b0b3df90 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -715,13 +715,11 @@ static int add_ref_to_list(const char *refname,
static void add_changes_to_bloom_filter(struct bloom_filter
On 10/9/2018 7:12 PM, Jeff King wrote:
On Tue, Oct 09, 2018 at 05:14:50PM -0400, Jeff King wrote:
Hmph. It really sounds like we could do better with a custom RLE
solution. But that makes me feel like I'm missing something, because
surely I can't invent something better than the state of the ar
On Thu, Oct 11, 2018 at 12:36:47PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Oct 11 2018, SZEDER Gábor wrote:
>
> > Fourth and hopefully final round of fixing occasional test failures when
> > run with 'GIT_TEST_SPLIT_INDEX=yes'. The only code change is the
> > extraction of a helper fun
1 - 100 of 136 matches
Mail list logo
