On 8/8/2019 2:59 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>>> --- a/Documentation/config/merge.txt
>>> +++ b/Documentation/config/merge.txt
>>> @@ -54,7 +54,8 @@ merge.directoryRenames::
>>> moved into the new directory. If set to "conflict", a conflict
>>> will be rep
On 8/8/2019 4:07 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> However, Stollee's commit message started with "The
>> 'feature.experimental' setting includes config options that are not
>> committed to become defaults".
>>
>> If these are settings that are "intended" but not "committed"
On 8/8/2019 4:31 PM, Elijah Newren wrote:
> On Thu, Aug 8, 2019 at 12:12 PM Derrick Stolee wrote:
>>
>> On 8/8/2019 2:59 PM, Junio C Hamano wrote:
>>> Elijah Newren writes:
>>>
>>>>> --- a/Documentation/config/merge.txt
>>>>
On 8/13/2019 5:08 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> "Derrick Stolee via GitGitGadget" writes:
>>
>>> * Update docs and 0 constant in feature.experimental around
>>>merge.directoryRenames.
>>
>> I somehow
On 8/14/2019 6:32 AM, Derrick Stolee wrote:
> On 8/13/2019 5:08 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> "Derrick Stolee via GitGitGadget" writes:
>>>
>>>> * Update docs and 0 constant in feature.experimental around
&g
On 8/14/2019 10:34 PM, Emily Shaffer wrote:
> Make it easier for users who encounter a bug to send a report by
> collecting some state information, intended to be viewed by humans
> familiar with Git.
This is an excellent idea! VFS for Git has a similar "diagnose" command
that collects logs, confi
p; *fmt) {
da4589ce 481) strbuf_addch(&buf_payload, ' ' );
da4589ce 482) maybe_append_string_va(&buf_payload, fmt, ap);
upload-pack.c
a8d662e3 130) return readsz;
820a5361 149) BUG("packfile_uris requires sideband-all");
a8d662e3 354) send_client_data(1, output_state.
On 8/18/2019 2:27 PM, SZEDER Gábor wrote:
> Remove the unused fields 'status', 'arg_alloc', 'arg_nr' and 'args'
> from 'struct line_log_data'. They were already part of the struct
> when it was introduced in commit 12da1d1f6 (Implement line-history
> search (git log -L), 2013-03-28), but as far as
On 8/18/2019 2:27 PM, SZEDER Gábor wrote:
> Line-level log performs a preprocessing step in
> prepare_revision_walk(), during which it filters and rewrites history
> to keep only commits modifying the given line range. This
> preprocessing causes significant delay before the first commit is
> show
On 8/18/2019 2:28 PM, SZEDER Gábor wrote:
> To be clear: this patch doesn't actually optimize the line-level log,
> but merely moves most of the work from the preprocessing step to the
> history travelsal, so the commits modifying the line range can be
s/travelsal/traversal/
-Stolee
On 8/19/2019 9:03 AM, SZEDER Gábor wrote:
> On Mon, Aug 19, 2019 at 08:00:11AM -0400, Derrick Stolee wrote:
>> On 8/18/2019 2:27 PM, SZEDER Gábor wrote:
>>> Line-level log performs a preprocessing step in
>>> prepare_revision_walk(), during which it filters and rewrit
On 8/19/2019 11:02 AM, SZEDER Gábor wrote:
> On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:
>> Note that I don't include the "without patch" numbers. For some
>> reason the path provided is particularly nasty and caused 20,000+
>> missi
On 8/16/2019 2:11 PM, Jeff King wrote:
> On Thu, Aug 15, 2019 at 10:01:04PM -0400, Derrick Stolee wrote:
>
>> Here is today's test coverage report.
>
> Are the scripts you use to generate these available somewhere?
The scripts I originally used are available in c
On 8/20/2019 2:37 PM, Garima Singh via GitGitGadget wrote:
> Hey Git contributors!
>
> My name is Garima Singh and I work at Microsoft. I recently started working
> closely with the Microsoft team contributing to the git client ecosystem. I
> am very glad to have the opportunity to work with this
On 8/20/2019 2:49 PM, René Scharfe wrote:
> Use QSORT_S instead of QSORT, which allows passing the repository
> pointer to the comparison function without using a static variable.
Makes sense.
> -static struct repository *sort_ambiguous_repo;
> -static int sort_ambiguous(const void *a, const void
On 8/21/2019 7:04 AM, SZEDER Gábor wrote:
> With rename detection enabled the line-level log is able to trace the
> evolution of line ranges across whole-file renames [1]. Alas, to
> achieve that it uses the diff machinery very inefficiently, making the
> operation very slow [2]. And since rename
On 8/21/2019 1:35 PM, SZEDER Gábor wrote:
> On Wed, Aug 21, 2019 at 11:53:28AM -0400, Derrick Stolee wrote:
>> On 8/21/2019 7:04 AM, SZEDER Gábor wrote:
>>> With rename detection enabled the line-level log is able to trace the
>>> evolution of line ranges across whole-
On 8/21/2019 5:52 PM, Elijah Newren wrote:
> On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget
> wrote:
>>
>> This RFC includes a potential direction to make the sparse-checkout more
>> user-friendly. While there, I also present a way to use a limited set
On 8/21/2019 6:15 PM, SZEDER Gábor wrote:
> On Wed, Aug 21, 2019 at 12:18:33PM -0700, Derrick Stolee via GitGitGadget
> wrote:
>> This reverts commit 65f099b3988198f0fdf3ef7a21dc01c556d21fff, which
>> removed logic for avoiding extra cost in "git checkout -b" in favor
On 8/21/2019 6:31 PM, SZEDER Gábor wrote:
> On Wed, Aug 21, 2019 at 12:18:32PM -0700, Derrick Stolee via GitGitGadget
> wrote:
>> As we were integrating Git 2.23.0 into VFS for Git, we discovered that "git
>> checkout -b new-branch" went from 0.3s to 10+s on the Win
On 8/21/2019 11:16 PM, Elijah Newren wrote:
> Hi,
>
> On Wed, Aug 21, 2019 at 12:21 PM Derrick Stolee via GitGitGadget
> wrote:
>>
>> As we were integrating Git 2.23.0 into VFS for Git, we discovered that "git
>> checkout -b new-branch" went from 0.3s to
On 8/18/2019 4:04 PM, brian m. carlson wrote:
> Instead of hard-coding the hash size, use the_hash_algo to look up the
> hash size at runtime. Remove the #define constant which was used to
> hold the hash length, since writing the expression with the_hash_algo
> provide enough documentary value on
On 8/22/2019 9:10 AM, Derrick Stolee wrote:
> On 8/21/2019 5:52 PM, Elijah Newren wrote:
>> On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget
>>> For example, if we add A/B/C as a recursive folder, then we add the
>>> following patterns
On 8/22/2019 4:41 AM, SZEDER Gábor wrote:
> On Wed, Aug 21, 2019 at 07:35:15PM +0200, SZEDER Gábor wrote:
>> So line-level log clearly computes a lot less diffs than
>> '--full-history', though still about 50% more than a regular
>> pathspec-limited history traversal. Looking at the commit-parent
On 8/22/2019 12:26 PM, SZEDER Gábor wrote:
> On Thu, Aug 22, 2019 at 09:01:44AM -0700, Junio C Hamano wrote:
>> SZEDER Gábor writes:
>>
>>> Well, that fruit hung much lower than I though, just look at the size
>>> of the WIP patch below. I just hope that there are no unexpected
>>> surprises, but
On 8/22/2019 10:17 PM, brian m. carlson wrote:
> On 2019-08-22 at 14:04:16, Derrick Stolee wrote:
>> On 8/18/2019 4:04 PM, brian m. carlson wrote:
>>> diff --git a/midx.c b/midx.c
>>> index d649644420..f29afc0d2d 100644
>>> --- a/midx.c
>>> ++
On 8/22/2019 5:12 PM, Elijah Newren wrote:
> On Thu, Aug 22, 2019 at 1:24 PM Junio C Hamano wrote:
>>
>> Elijah Newren writes:
>>
>>> Questions, comments, or concerns with this proposal? Alternative
>>> proposals? If inclusion is acceptable, are there any other tasks that
>>> need to be complet
On 8/24/2019 1:40 AM, Elijah Newren wrote:
> On Thu, Aug 22, 2019 at 6:10 AM Derrick Stolee wrote:
>>
>> On 8/21/2019 5:52 PM, Elijah Newren wrote:
>>> On Tue, Aug 20, 2019 at 8:12 AM Derrick Stolee via GitGitGadget
>>> wrote:
>
>
>>>> He
On 8/26/2019 2:16 PM, Elijah Newren wrote:
> On Mon, Aug 26, 2019 at 6:29 AM Derrick Stolee wrote:
>>
>> On 8/24/2019 1:40 AM, Elijah Newren wrote:
>>> On Thu, Aug 22, 2019 at 6:10 AM Derrick Stolee wrote:
>>>>
>>>> On 8/21/2019 5:52 PM, Elijah New
On 8/26/2019 7:52 PM, Elijah Newren wrote:
> Test t6006.71 ("oneline with empty message") was creating two commits
> with simple commit messages, and then running filter-branch to rewrite
> the commit messages to be empty. This test was written this way because
> the --allow-empty-message option t
On 8/26/2019 7:52 PM, Elijah Newren wrote:
> fast-export and fast-import can easily handle the simple rewrite that
> was being done by filter-branch, and should be significantly faster on
> systems with a slow fork. Timings from before and after on two laptops
> that I have access to (measured via
On 8/26/2019 7:52 PM, Elijah Newren wrote:
> Scripts external to git could source $(git --exec-path)/git-sh-setup (as
> we document in Documentation/git-sh-setup.txt). This will in turn
> source git-sh-i18n, which will setup some handy internationalization
> infrastructure. However, git-sh-i18n h
On 8/26/2019 7:52 PM, Elijah Newren wrote:
> filter-branch suffers from a huge number of pitfalls that can result in
> incorrectly rewritten history, and many of the problems can easily go
> undetected until the new repository is in use. This can result in
> problems ranging from an even messier h
On 8/26/2019 7:52 PM, Elijah Newren wrote:
> Following up on the suggestion to make git.git smaller and shed non-core
> tools, here's an RFC series to do so with git-filter-branch. This
> series first removes dependencies on git-filter-branch (of which there
> were very few), and then deletes git-
On 8/25/2019 10:43 PM, Eric Wong wrote:
> Otherwise, the hashmap_entry.next field appears to remain
> uninitialized, which can lead to problems when
> add_lines_to_move_detection calls hashmap_add.
>
> I found this through manual inspection when converting
> hashmap_add callers to take "struct has
On 8/25/2019 10:43 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.
Overall I like this change. I'll need to
On 8/25/2019 10:43 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 o
On 8/25/2019 10:43 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 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
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/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/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 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 '
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 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 @
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/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/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/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 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 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/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/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/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 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 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 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 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 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 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/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/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: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/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/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/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/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/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 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 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 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 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
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
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
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;
>
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 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 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 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:
> 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:
> 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:
> 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 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: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 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 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/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/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/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/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:
> 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:
> 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:
> 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 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 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:
> 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:
> 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/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
901 - 1000 of 2158 matches
Mail list logo
