On 10/6/2019 12:10 AM, Elijah Newren wrote:
> On Thu, Sep 19, 2019 at 1:46 PM Derrick Stolee via GitGitGadget
> wrote:
>>
>> From: Derrick Stolee
>>
>> The instructions for disabling a sparse-checkout to a full
>> working directory are complicated and non-
On 10/5/2019 8:30 PM, Elijah Newren wrote:
> On Sat, Oct 5, 2019 at 3:44 PM Elijah Newren wrote:
>>
>> On Thu, Sep 19, 2019 at 3:07 PM Derrick Stolee via GitGitGadget
>> wrote:
>>> +static int write_patterns_and_update(struct pattern_list *pl)
>>&g
On 10/5/2019 3:40 PM, Elijah Newren wrote:
> On Thu, Sep 19, 2019 at 3:06 PM Derrick Stolee via GitGitGadget
> wrote:
>
>> During the 'git sparse-checkout init' call, we must first look
>> to see if HEAD is valid, or else we will fail while trying to
>> up
On 10/4/2019 4:52 AM, Johannes Schindelin wrote:
> Hi George,
>
> if you have Visual Studio, you could also check out the `vs/master`
> branch of https://github.com/git-for-windows/git and build Git inside
> Visual Studio. The tests can still be run in Git Bash (the regular one
> this time, no nee
On 10/2/2019 2:18 AM, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>> Is that the expected behavior? In a sparse-checkout, wouldn't you _want_
>> Git to report things outside the cone?
>
> That should be optional, I would think. When you declare "by
On 10/1/2019 9:06 AM, Matheus Tavares Bernardino wrote:
> Hi,
>
> During Git Summit it was mentioned that git-grep searches outside
> sparsity pattern which is not aligned with user expectation. I took a
> quick look at it and it seems the reason is
> builtin/grep.c:grep_cache() (which also greps
On 10/1/2019 12:54 PM, Elijah Newren wrote:
> On Tue, Oct 1, 2019 at 9:48 AM Derrick Stolee wrote:
>>
>> On 9/19/2019 10:43 AM, Derrick Stolee via GitGitGadget wrote:
>>> This series makes the sparse-checkout feature more user-friendly. While
>>> there, I also p
On 9/19/2019 10:43 AM, Derrick Stolee via GitGitGadget wrote:
> This series makes the sparse-checkout feature more user-friendly. While
> there, I also present a way to use a limited set of patterns to gain a
> significant performance boost in very large repositories.
>
> Sparse-c
On 9/27/2019 8:21 AM, Johannes Schindelin wrote:
> Hi,
>
>
> On Thu, 26 Sep 2019, Alex Henrie wrote:
>
>> Signed-off-by: Alex Henrie
>
> Hrm, the commit message should reflect Stolee's careful consideration,
> no? An empty commit message won't be helpful e.g. when cherry-picking on
> top of a
On 9/26/2019 10:45 PM, Jeff King wrote:
> On Tue, Sep 24, 2019 at 08:01:58PM -0600, Alex Henrie wrote:
>
>> diff --git a/wrapper.c b/wrapper.c
>> index c55d7722d7..c23ac6adcd 100644
>> --- a/wrapper.c
>> +++ b/wrapper.c
>> @@ -469,13 +469,12 @@ int git_mkstemps_mode(char *pattern, int suffix_len,
On 9/26/2019 11:24 AM, Philip Oakley wrote:
> On 26/09/2019 14:36, Derrick Stolee wrote:
>>>> Another good reason to use "sizeof(var)" instead of sizeof(type)". :)
>>> That is indeed a very good reason, in addition to getting the type right
>>> autom
On 9/26/2019 9:22 AM, Johannes Schindelin wrote:
> Hi Peff,
>
> On Mon, 23 Sep 2019, Jeff King wrote:
>
>> On Thu, Sep 19, 2019 at 10:48:30PM +0200, René Scharfe wrote:
>>
>>> Use the macro COPY_ARRAY to copy array elements and MOVE_ARRAY to do the
>>> same for moving them backwards in an array w
On 9/24/2019 10:01 PM, Alex Henrie wrote:
> Signed-off-by: Alex Henrie
> ---
> wrapper.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/wrapper.c b/wrapper.c
> index c55d7722d7..c23ac6adcd 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -469,13 +469,12 @@ in
On 9/24/2019 10:01 PM, Alex Henrie wrote:
> Signed-off-by: Alex Henrie
> ---
> diffcore-break.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/diffcore-break.c b/diffcore-break.c
> index 875aefd3fe..f6ab74141b 100644
> --- a/diffcore-break.c
> +++ b/diff
On 9/24/2019 10:01 PM, Alex Henrie wrote:
> Signed-off-by: Alex Henrie
> ---
> commit-graph.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/commit-graph.c b/commit-graph.c
> index 9b02d2c426..659f4bb4f4 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -1534,7 +1534,6 @@ static
On 9/26/2019 3:20 AM, Jeff King wrote:
> On Tue, Sep 24, 2019 at 04:52:56PM -0700, Emily Shaffer wrote:
>
I've cc'd g...@sfconservancy.org here, because I think it's important for
all of the project committee members to endorse it (and because the
document puts us on the hook for en
On 9/25/2019 9:36 AM, Pierre Tardy wrote:
>>> As a community, our number one goal is for Git to continue to be the best
>>> distributed version control system. At minimum, it should continue to be
>>> the most widely-used DVCS.
>>
>> I'd rather we stated our goal in terms of what problems we are tr
On 9/23/2019 9:03 PM, Eric Wong wrote:
> Patches 1-11 are largely unchanged from the original series with the
> exception of 2, which is new and posted at:
>
> https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
>
> 12-17 take further steps to get us away from hashmap_entry b
On 9/23/2019 9:03 PM, Eric Wong wrote:
> Using `container_of' can be verbose and choosing names for
> intermediate "struct hashmap_entry" pointers is a hard problem.
> So introduce "*_entry" APIs inspired by similar linked-list
> APIs in the Linux kernel.
>
> Unfortunately, `__typeof__' is not por
On 9/23/2019 9:03 PM, Eric Wong wrote:
> This macro is popular within the Linux kernel for supporting
> intrusive data structures such as linked lists, red-black trees,
> and chained hash tables while allowing the compiler to do
> type checking.
>
> I intend to use this to remove the limitation of
On 9/23/2019 9:03 PM, Eric Wong wrote:
> This is a step towards removing the requirement for
> hashmap_entry being the first field of a struct.
>
> Signed-off-by: Eric Wong
> ---
> diff.c | 19 ---
> diffcore-rename.c | 11 +++
> hashmap.c
On 9/23/2019 9:03 PM, Eric Wong wrote:
> This is less error-prone than "const void *" as the compiler
> now detects invalid types being passed.
[snip]
> diff --git a/hashmap.c b/hashmap.c
> index 092236c09a..bdf33e0381 100644
> --- a/hashmap.c
> +++ b/hashmap.c
> @@ -218,7 +218,8 @@ void hashmap_ad
On 9/23/2019 9:03 PM, Eric Wong wrote:
> This is less error-prone than "const void *" as the compiler
> now detects invalid types being passed.
[snip]
> diff --git a/hashmap.h b/hashmap.h
> index 40bcc64289..2a4b4a3954 100644
> --- a/hashmap.h
> +++ b/hashmap.h
> @@ -74,7 +74,8 @@
> *
On 9/23/2019 9:03 PM, Eric Wong wrote:
> C compilers do type checking to make life easier for us. So
> rely on that and update all hashmap_entry_init callers to take
> "struct hashmap_entry *" to avoid future bugs while improving
> safety and readability.
[snip]
> @@ -244,9 +244,9 @@ void hashmap_
On 9/23/2019 9:03 PM, Eric Wong wrote:
> Assigning hashmap_entry.hash manually leaves hashmap_entry.next
> uninitialized, which can be dangerous once the hashmap_entry is
> inserted into a hashmap. Detect those assignments and use
> hashmap_entry_init, instead.
I appreciate this future-proofing!
On 9/23/2019 9:03 PM, Eric Wong wrote:
> Since these macros already take a `keyvar' pointer of a known type,
> we can rely on OFFSETOF_VAR to get the correct offset without
> relying on non-portable `__typeof__' and `offsetof'.
>
> Argument order is also rearranged, so `keyvar' and `member' are
>
On 9/22/2019 11:17 PM, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm working in an unusual setup on WIndows. I need to 'git clone' over
> SSH, but a third party program has to handle the tunnel. It happens by
> using this git configuration:
>
> git config --global core.sshcommand "tunnel.exe .
On 9/24/2019 2:44 AM, Jeff King wrote:
> We've never had a formally written Code of Conduct document. Though it
> has been discussed off and on over the years, for the most part the
> behavior on the mailing list has been good enough that nobody felt the
> need to push one forward.
>
> However, ev
On 9/19/2019 10:23 AM, Derrick Stolee wrote:
> Here is today's test coverage report.
And I took a close look at the report, looking for interesting cases
that are not covered. Most of the uncovered lines were due to simple
refactors or error conditions. I point out a few below that took
On 9/19/2019 12:30 PM, Derrick Stolee wrote:
> During the Virtual Git Contributors' Summit, Dscho brought up the topic of
> "Inclusion & Diversity". We discussed ideas for how to make the community
> more welcoming to new contributors of all kinds. Let's discuss so
On 9/19/2019 5:46 PM, SZEDER Gábor wrote:
> 'git name-rev' is implemented using a recursive algorithm, and,
> consequently, it can segfault in deep histories (e.g. WebKit), and
> thanks to a test case demonstrating this limitation every test run
> results in a dmesg entry logging the segfaulting gi
On 9/19/2019 5:47 PM, SZEDER Gábor wrote:
> The name_rev() function's 'tip_name' parameter is a freshly
> xstrdup()ed string, so when name_rev() invokes...
This patch 15/15 seems to be the same as your 14/15, and
we should use your _other_ 15/15, right?
Thanks,
-Stolee
On 9/19/2019 5:47 PM, SZEDER Gábor wrote:
> At the beginning of the recursive name_rev() function it creates a new
> 'struct rev_name' instance for each previously unvisited commit or, if
> this visit results in better name for an already visited commit, then
> updates the 'struct rev_name' instanc
On 9/19/2019 5:47 PM, SZEDER Gábor wrote:
> The 'if (deref) { ... }' condition near the beginning of the recursive
> name_rev() function can only ever be true in the first invocation,
> because the 'deref' parameter is always 0 in the subsequent recursive
> invocations.
>
> Extract this condition
On 9/19/2019 5:47 PM, SZEDER Gábor wrote:
> In a later patch in this series we'll want to do this in two places.
>
> Signed-off-by: SZEDER Gábor
> ---
> builtin/name-rev.c | 40 +++-
> 1 file changed, 27 insertions(+), 13 deletions(-)
>
> diff --git a/builtin
On 9/19/2019 5:47 PM, SZEDER Gábor wrote:
> In 'builtin/name-rev.c' in the name_rev() function there is a loop
> iterating over all parents of the given commit, and the loop body
> looks like this:
>
> if (parent_number > 1) {
> if (generation > 0)
> // do stuff #1
> else
> /
On 9/19/2019 5:47 PM, SZEDER Gábor wrote:
> Signed-off-by: SZEDER Gábor
> ---
> builtin/name-rev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/name-rev.c b/builtin/name-rev.c
> index e406ff8e17..dec2228cc7 100644
> --- a/builtin/name-rev.c
> +++ b/builtin/nam
On 9/19/2019 4:59 PM, Derrick Stolee wrote:
> On 9/19/2019 10:43 AM, Derrick Stolee via GitGitGadget wrote:
>> @@ -848,6 +953,10 @@ static int add_patterns_from_buffer(char *buf, size_t
>> size,
>> int i, lineno = 1;
>> char *entry;
>>
On 9/19/2019 6:16 PM, Jeff King wrote:
> On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:
>>
>> 5. Advertise that Git wants new contributors
>>
> This point is the one I'm least on board with. Not because I'm not
> thrilled to have new contribu
On 9/19/2019 10:43 AM, Derrick Stolee via GitGitGadget wrote:
> @@ -848,6 +953,10 @@ static int add_patterns_from_buffer(char *buf, size_t
> size,
> int i, lineno = 1;
> char *entry;
>
> + pl->use_cone_patterns = core_sparse_checkout_cone;
>
During the Virtual Git Contributors' Summit, Dscho brought up the topic of
"Inclusion & Diversity". We discussed ideas for how to make the community
more welcoming to new contributors of all kinds. Let's discuss some of
the ideas we talked about, and some that have been growing since.
Feel free to
From: Derrick Stolee
The 'git sparse-checkout set' subcommand takes a list of patterns
as arguments and writes them to the sparse-checkout file. Then, it
updates the working directory using 'git read-tree -mu HEAD'.
The 'set' subcommand will replace the entire c
in git-read-tree.
[2] https://stackoverflow.com/a/4909267/127088Is it possible to do a sparse
checkout without checking out the whole repository first?
[3] http://www.marcoyuen.com/articles/2016/06/07/git-sparse.htmlA blog post
of a user's extra "git-sparse" helper.
[4]
htt
From: Derrick Stolee
The sparse-checkout feature can have quadratic performance as
the number of patterns and number of entries in the index grow.
If there are 1,000 patterns and 1,000,000 entries, this time can
be very significant.
Create a new Boolean config option, core.sparseCheckoutCone
From: Derrick Stolee
The parent and recursive patterns allowed by the "cone mode"
option in sparse-checkout are restrictive enough that we
can avoid using the regex parsing. Everything is based on
prefix matches, so we can use hashsets to store the prefixes
from the sparse-checkout
From: Derrick Stolee
The 'git sparse-checkout set' subcommand takes a list of patterns
and places them in the sparse-checkout file. Then, it updates the
working directory to match those patterns. For a large list of
patterns, the command-line call can get very cumbersome.
Add a '
From: Derrick Stolee
To make the cone pattern set easy to use, update the behavior of
'git sparse-checkout [init|set]'.
Add '--cone' flag to 'git sparse-checkout init' to set the config
option 'core.sparseCheckoutCone=true'.
When running 'git s
From: Derrick Stolee
The instructions for disabling a sparse-checkout to a full
working directory are complicated and non-intuitive. Add a
subcommand, 'git sparse-checkout disable', to perform those
steps for the user.
Signed-off-by: Derrick Stolee
---
Documentation/git-sparse-ch
From: Derrick Stolee
The sparse-checkout feature is mostly hidden to users, as its
only documentation is supplementary information in the docs for
'git read-tree'. In addition, users need to know how to edit the
.git/info/sparse-checkout file with the right patterns, then run
the a
From: Derrick Stolee
The sparse-checkout feature in "cone mode" can use the fact that
the recursive patterns are "connected" to the root via parent
patterns to decide if a directory is entirely contained in the
sparse-checkout or entirely removed.
In these cases, we can sk
From: Derrick Stolee
Getting started with a sparse-checkout file can be daunting. Help
users start their sparse enlistment using 'git sparse-checkout init'.
This will set 'core.sparseCheckout=true' in their config, write
an initial set of patterns to the sparse-checkout fi
From: Derrick Stolee
When someone wants to clone a large repository, but plans to work
using a sparse-checkout file, they either need to do a full
checkout first and then reduce the patterns they included, or
clone with --no-checkout, set up their patterns, and then run
a checkout manually. This
trbuf_addf(&buf_payload, "alias:%s argv:[", alias);
742ed633 303) sq_append_quote_argv_pretty(&buf_payload, argv);
742ed633 304) strbuf_addch(&buf_payload, ']');
742ed633 335) strbuf_addstr(&buf_payload, "git");
742ed633 336) if (cmd->argv[0])
742
On 9/18/2019 12:35 PM, René Scharfe wrote:
> Pass the target strbuf to the callback function grab_nth_branch_switch()
> by reference so that it can add the result string directly instead of
> having it put the string into a temporary strbuf first. This gets rid
> of an extra allocation and a strin
On 9/18/2019 10:56 AM, Elijah Newren wrote:
> On Wed, Sep 18, 2019 at 6:55 AM Derrick Stolee wrote:
>>
>> On 8/23/2019 7:30 PM, Elijah Newren wrote:
>>> On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget
>>> wrote:
>>>>
> ...
>
On 8/23/2019 7:30 PM, Elijah Newren wrote:
> On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget
> wrote:
>>
>> From: Derrick Stolee
>>
>> The 'git sparse-checkout add' subcommand takes a list of patterns
>> over stdin and writes them to
On 8/23/2019 7:17 PM, Elijah Newren wrote:
> On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget
> wrote:
>>
>> From: Derrick Stolee
>>
>> When someone wants to clone a large repository, but plans to work
>> using a sparse-checkout file, they
On 9/18/2019 4:43 AM, Jakub Narebski wrote:
> Derrick Stolee writes:
>> On 6/25/2019 3:51 AM, Jakub Narebski wrote:
>>> Jakub Narebski writes:
>>>> Derrick Stolee writes:
> [...]
>>>> O.K., so the "generation number v2 (legacy)" would be i
On 9/16/2019 6:36 PM, SZEDER Gábor wrote:
> On Mon, Aug 26, 2019 at 09:29:58AM -0700, Garima Singh via GitGitGadget wrote:
>> From: Garima Singh
>>
>> Add --[no-]progress to git commit-graph write and verify.
>> The progress feature was introduced in 7b0f229
>> ("commit-graph write: add progress
On 9/13/2019 8:26 PM, Josh Steadmon wrote:
> Add a new "overload" event type for trace2 event destinations. Write
> this event into the sentinel file created by the trace2.maxFiles
> feature. Bump up the event format version since we've added a new event
> type.
>
> Writing this message into the s
On 9/15/2019 5:18 PM, Masaya Suzuki wrote:
> During git-fetch, the client checks if the advertised tags' OIDs are
> already in the fetch request's want OID set. This check is done in a
> linear scan. For a repository that has a lot of refs, repeating this
> scan takes 15+ minutes. In order to speed
On 9/15/2019 1:07 PM, René Scharfe wrote:
> Let commit_list_count() count the number of parents instead of
> duplicating it. Also store the result in an unsigned int, as that's
> what the function returns, and the count is never negative.
I was unfamiliar with this method, but it obviously remove
On 9/12/2019 10:44 AM, Jeff King wrote:
> When the client has asked for certain shallow options like
> "deepen-since", we do a custom rev-list walk that pretends to be
> shallow. Before doing so, we have to disable the commit-graph, since it
> is not compatible with the shallow view of the reposito
On 9/12/2019 10:44 AM, Jeff King wrote:
> Commit 43d3561805 (commit-graph write: don't die if the existing graph
> is corrupt, 2019-03-25) added an environment variable we use only in the
> test suite, $GIT_TEST_COMMIT_GRAPH_DIE_ON_LOAD. But it put the check for
> this variable at the very top of p
On 9/12/2019 10:23 AM, Jeff King wrote:
> On Thu, Sep 12, 2019 at 08:23:49AM -0400, Derrick Stolee wrote:
>
>>> That creates an interesting problem for commits that have _already_ been
>>> parsed using the commit graph. Their commit->object.parsed flag is set,
>>
On 9/11/2019 10:07 PM, Taylor Blau wrote:>>
>> +# A few subtle things about the request in this test:
>> +#
>> +# - the server must have commit-graphs present and enabled
>
> I think "enabled" may be somewhat redundant, at least since some recent
> changes to enable this by default. (As an aside,
On 9/11/2019 9:11 PM, Jeff King wrote:
> On Wed, Sep 11, 2019 at 08:18:46PM -0400, Jeff King wrote:
>
>>> That creates an interesting problem for commits that have _already_ been
>>> parsed using the commit graph. Their commit->object.parsed flag is set,
>>> their commit->graph_pos is set, but the
On 9/11/2019 8:04 PM, Jeff King wrote:
> When the client has asked for certain shallow options like
> "deepen-since", we do a custom rev-list walk that pretends to be
> shallow. Before doing so, we have to disable the commit-graph, since it
> is not compatible with the shallow view of the repositor
On 9/11/2019 11:37 AM, William Baker via GitGitGadget wrote:
> Hello Git contributors!
>
> My name is William Baker and I work at Microsoft. Over the past few years
> I've worked closely with the Microsoft team contributing to the git
> ecosystem and I'm excited to start working with the community
On 8/23/2019 7:02 PM, Elijah Newren wrote:
> On Tue, Aug 20, 2019 at 8:13 AM Derrick Stolee via GitGitGadget
> wrote:
>> +static int sc_read_tree(void)
>> +{
>> + struct argv_array argv = ARGV_ARRAY_INIT;
>> + int result = 0;
>> + argv_array
On 8/23/2019 7:02 PM, Elijah Newren wrote:
> On Tue, Aug 20, 2019 at 8:13 AM Derrick Stolee via GitGitGadget
> wrote:
>>
>> From: Derrick Stolee
>>
>> Getting started with a sparse-checkout file can be daunting. Help
>> users start their sparse enlist
On 9/9/2019 7:21 PM, Cameron Steffen via GitGitGadget wrote:
> From: Cameron Steffen
>
> move an incorrectly placed backtick
The change below is simple enough, but we prefer using full sentences in the
commit messages. This includes capitalization and punctuation.
Thanks,
-Stolee
> Signed-of
On 9/9/2019 7:21 PM, Cameron Steffen via GitGitGadget wrote:
> Edit: I need permission to submit please
Hi Cameron.
When using GitGitGadget, your PR description becomes your cover letter on the
mailing list. This is a great place for you to describe how you discovered this
problem and if you ha
On 9/6/2019 4:42 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> I suppose so. But I think the "stock git without any other job
>> infrastructure" case would still benefit.
>
> Oh, no question about it.
>
> I did question if an automatic writing would benefit the side that
> receives a push
On 9/6/2019 1:04 PM, Jeff King wrote:
> On Fri, Sep 06, 2019 at 12:48:05PM -0400, Derrick Stolee wrote:
>
>>> diff --git a/revision.h b/revision.h
>>> index 4134dc6029..5c0b831b37 100644
>>> --- a/revision.h
>>> +++ b/revision.h
>>> @@ -33,7
On 9/6/2019 1:04 PM, Jeff King wrote:
> On Fri, Sep 06, 2019 at 12:48:05PM -0400, Derrick Stolee wrote:
>
>>> diff --git a/revision.h b/revision.h
>>> index 4134dc6029..5c0b831b37 100644
>>> --- a/revision.h
>>> +++ b/revision.h
>>> @@ -33,7
On 9/5/2019 4:37 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> Do we want to to have fetch.writeCommitGraph, receive.writeCommitGraph,
>> and then a master transfer.writeCommitGraph?
>
> If anything, it may be good for consistency.
>
> I am not sure if it is a good idea to trigger writing
On 9/6/2019 2:19 AM, Jeff King wrote:
> On Thu, Sep 05, 2019 at 06:04:57PM -0400, Taylor Blau wrote:
>
>> @@ -846,7 +847,11 @@ static void write_graph_chunk_data(struct hashfile *f,
>> int hash_len,
>> if (parse_commit_no_graph(*list))
>> die(_("unable to parse c
On 9/5/2019 6:04 PM, Taylor Blau wrote:
> When invoking 'git commit-graph' in a corrupt repository, one can cause
> a segfault when ancestral commits are corrupt in one way or another.
> This is due to two function calls in the 'commit-graph.c' code that may
> return NULL, but are not checked for N
On 9/5/2019 2:47 AM, Jeff King wrote:
> On Wed, Sep 04, 2019 at 05:18:47PM -0400, Taylor Blau wrote:
>
>> All of this makes sense to me, so I'm wondering what part(s) of this you
>> feel are worth addressing in this first patch series. Presumably, there
>> is a longer series that we _could_ write
On 9/4/2019 5:21 PM, Taylor Blau wrote:
> Hi Garima,
>
> On Wed, Sep 04, 2019 at 02:25:55PM -0400, Garima Singh wrote:
>>
>> On 9/3/2019 10:22 PM, Taylor Blau wrote:
>>> Hi,
>>>
>>> I was running some of the new 'git commit-graph' commands, and noticed
>>> that I could consistently get 'git commit
On 9/3/2019 3:42 PM, Jonathan Tan wrote:
> When cherry-picking (for example), new trees may be constructed. During
> this process, Git checks whether these trees exist. However, in a
> partial clone, this causes a lazy fetch to occur, which is both
> unnecessary (because Git has already constructed
On 9/3/2019 3:05 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
>> diff --git a/builtin/fetch.c b/builtin/fetch.c
>> index 53ce99d2bb..d36a403859 100644
>> --- a/builtin/fetch.c
>> +++ b/builtin/fetch.c
>> @@ -23,6 +23,7 @
From: Derrick Stolee
The first consumer of pattern-matching filenames was the
.gitignore feature. In that context, storing a list of patterns
as a 'struct exclude_list' makes sense. However, the
sparse-checkout feature then adopted these structures and methods,
but with the opposi
: [PATCH 8/9] sparse-checkout: use hashmaps for cone patterns
[2] https://public-inbox.org/git/cover.1558030802.git.matv...@google.com/
[RFC PATCH 0/3] implement composite filters
[3] https://public-inbox.org/git/20190828201824.1255-1-...@jonsimons.org/
[PATCH 0/2] partial-clone: fix two issues wi
From: Derrick Stolee
The first consumer of pattern-matching filenames was the
.gitignore feature. In that context, storing a list of patterns
as a list of 'struct exclude' items makes sense. However, the
sparse-checkout feature then adopted these structures and methods,
but with th
From: Derrick Stolee
The first consumer of pattern-matching filenames was the
.gitignore feature. In that context, storing a list of patterns
as a 'struct exclude_list' makes sense. However, the
sparse-checkout feature then adopted these structures and methods,
but with the opposi
From: Derrick Stolee
The first consumer of pattern-matching filenames was the
.gitignore feature. In that context, storing a list of patterns
as a 'struct exclude_list' makes sense. However, the
sparse-checkout feature then adopted these structures and methods,
but with the opposi
From: Derrick Stolee
The first consumer of pattern-matching filenames was the
.gitignore feature. In that context, storing a list of patterns
as a 'struct exclude_list' makes sense. However, the
sparse-checkout feature then adopted these structures and methods,
but with the opposi
rming well with no known issues.
Thanks, -Stolee
[1]
https://public-inbox.org/git/3c52385e5696887c40cab4a6b9b7923d60a0567c.1557330827.git.gitgitgad...@gmail.com/
[2]
https://public-inbox.org/git/b1de6af2-c015-098e-a656-e1b68056e...@gmail.com/
Derrick Stolee (1):
fetch: add fetch.writeCommitGra
From: Derrick Stolee
The commit-graph feature is now on by default, and is being
written during 'git gc' by default. Typically, Git only writes
a commit-graph when a 'git gc --auto' command passes the gc.auto
setting to actualy do work. This means that a commit-graph will
t
On 8/29/2019 8:43 PM, Taylor Blau wrote:
> Hi Elijah,
>
> On Thu, Aug 29, 2019 at 05:19:44PM -0700, Elijah Newren wrote:
>> Personally, although I understand the desire to support any possible
>> cases in general, *this is a performance hack*. As such, it should be
>> as simple and localized as p
On 8/29/2019 2:54 PM, Phillip Wood wrote:
> Hi Stolee
>
> On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
>> +
>> + if (argc == 3 && !strcmp(argv[1], "-b")) {
>> + /*
>> + * User ran 'git checkout -b '
From: Derrick Stolee
The 'git switch' command was created to separate half of the
behavior of 'git checkout'. It specifically has the mode to
do nothing with the index and working directory if the user
only specifies to create a new branch and change HEAD to that
bran
t checkout -b ' should do the fast thing, and we should check the
arguments directly.
This series makes 'git checkout -b ' do the same thing as 'git switch -c '.
Thanks, -Stolee
[1] https://public-inbox.org/git/pull.317.git.gitgitgad...@gmail.com/
Derr
On 8/29/2019 9:44 AM, Jeff King wrote:
> On Thu, Aug 29, 2019 at 09:12:38AM -0400, Derrick Stolee wrote:
>
>>> +test_expect_success 'partial clone with unresolvable sparse filter fails
>>> cleanly' '
>>> + test_must_fail git clone --no-local --no
On 8/29/2019 10:13 AM, Jeff King wrote:
> On Thu, Aug 29, 2019 at 08:58:55AM -0400, Derrick Stolee wrote:
>
>> However, I do have a theory: the process exits before flushing the
>> packet line. Adding this line before exit(1) should fix it:
>>
>> packet_writer_f
On 8/28/2019 4:18 PM, Jon Simons wrote:
> Handle a potential NULL 'sparse_oid_value' when attempting to load
> sparse filter exclusions by blob, to avoid segfaulting later during
> 'add_excludes_from_blob_to_list'.
>
> While here, uniquify the errors emitted to distinguish between the
> case that
On 8/28/2019 12:15 PM, SZEDER Gábor wrote:
> On Wed, Aug 28, 2019 at 11:39:44AM -0400, Jeff King wrote:
>> On Wed, Aug 28, 2019 at 10:54:12AM -0400, Jeff King wrote:
>>
Unfortunately, however, while running './t5516-fetch-push.sh -r 1,79
--stress' to try to reproduce a failure caused by t
. See the commit message for the race condition.
The thing I am worried about is that I replaced a die() statement with an
error() and exit() pair. Is that OK? Or is there a preferred option?
Thanks, -Stolee
[1] https://gvfs.visualstudio.com/ci/_build/results?buildId=16068
Derrick Stolee (1
101 - 200 of 2158 matches
Mail list logo
