On Thu, Sep 05, 2019 at 09:35:10PM +0200, Martin Ågren wrote:
> > > do also think it makes sense to first make the "softer" switch to
> > > Asciidoctor-by-default and get that particular hurdle behind us. Then,
> > > once we're ok with dropping AsciiDoc entirely, we can do the switch to
> > > an A
On Fri, Sep 06, 2019 at 04:55:46AM -0700, Carlo Arenas wrote:
> I'm interested to mentor/help too, but I am definitely not a (some
> people would even argue against "reliable") contributor but I might be
> better than nothing and could pass my "lessons learned" along, so
> hopefully next contribut
On Thu, Sep 05, 2019 at 12:39:59PM -0700, Emily Shaffer wrote:
> > Funding is still up in the air, but in the meantime I've tentatively
> > signed us up (we have until the 24th to have the funding committed).
> > Next we need mentors to submit projects, as well as first-time
> > contribution micro
The commit-graph tool may read a lot of commits, but it only cares about
parsing their metadata (parents, trees, etc) and doesn't ever show the
messages to the user. And so it should not need save_commit_buffer,
which is meant for holding onto the object data of parsed commits so
that we can show t
From: SZEDER Gábor
Commit 49bbc57a57 (commit-graph write: emit a percentage for all
progress, 2019-01-19) was a bit overeager when it added progress
percentages to the "Expanding reachable commits in commit graph" phase
as well, because most of the time the number of commits that phase has
to ite
We've been playing with commit graphs at GitHub and found a few bits of
low-hanging fruit (one liners -- it doesn't get any lower than that).
The first one is actually a resurrection of a patch from March:
https://public-inbox.org/git/20190322102817.19708-1-szeder@gmail.com/
where the prog
On Fri, Sep 06, 2019 at 02:46:22PM -0700, Junio C Hamano wrote:
> > You're right that we could isolate the new write to the refs we
> > just received. We could use the more cumbersome write_commit_graph()
> > method with a list of commit oids as starting points. I'm happy to
> > make that change i
On Fri, Sep 06, 2019 at 02:57:55PM -0700, Junio C Hamano wrote:
> > I think the "stock git without any other job infrastructure" is
> > a very important scenario. Putting the simplest version of
> > "commit-graph writes in-line with every push" seems to be ripe
> > for failure under load. I'd rath
On Fri, Sep 06, 2019 at 05:04:17PM -0400, Derrick Stolee wrote:
> 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
On Fri, Sep 06, 2019 at 11:29:47PM +, brian m. carlson wrote:
> On 2019-09-04 at 03:26:10, Jeff King wrote:
> > On Tue, Sep 03, 2019 at 08:51:19PM +0200, Martin Ågren wrote:
> > > When I posted v1, it turned into quite a thread [1] on AsciiDoc vs
> > > Asciidoctor vs Asciidoctor 2.0 and differ
Buenos dias
Necesitabas préstamos de dinero entre individuos para tratar
dificultades financieras para finalmente romper el punto muerto que
causar los bancos, rechazando sus archivos de aplicación de
créditos?
Soy un ciudadano francés retirado capaz de hacerte
Un préstamo de 5000 euros a 500
On Thu, Sep 5, 2019 at 12:27 PM SZEDER Gábor wrote:
>
> On Thu, Sep 05, 2019 at 08:47:35AM -0700, Elijah Newren wrote:
> > cmd_clean() had the following code structure:
> >
> > struct strbuf abs_path = STRBUF_INIT;
> > for_each_string_list_item(item, &del_list) {
> > strbuf_addstr(
On Thu, Sep 5, 2019 at 12:01 PM SZEDER Gábor wrote:
>
> On Thu, Sep 05, 2019 at 08:47:23AM -0700, Elijah Newren wrote:
> > This patch series fixes a few issues with git-clean:
>
> > * Failure to preserve both tracked and untracked files within a nested
> > Git repository reported a few weeks
On 2019-09-04 at 03:26:10, Jeff King wrote:
> On Tue, Sep 03, 2019 at 08:51:19PM +0200, Martin Ågren wrote:
> > When I posted v1, it turned into quite a thread [1] on AsciiDoc vs
> > Asciidoctor vs Asciidoctor 2.0 and differences in rendering. (I am on
> > Asciidoctor 1.5.5.)
>
> Yes, sadly I stil
Derrick Stolee writes:
> 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 benef
Derrick Stolee writes:
>>> + write_commit_graph_reachable(get_object_directory(),
>>> +commit_graph_flags,
>>> +&split_opts);
>>> + }
>>
>> As a low-impact change this is good.
>>
>> For longer term, i
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
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 when you brought up the usual "fetch.* and receive.*
for se
"Derrick Stolee via GitGitGadget" writes:
> I had started working on v2.23.0, but found adjacent-diff conflicts with
> md/list-objects-filter-combo [2] and js/partial-clone-sparse-blob [3]. Those
> branches are independent, but the conflicts with
> md/list-objects-filter-combo were more severe (a
Hi Birger,
On 06/09/2019 15:08, Birger Skogeng Pedersen wrote:
Hi Bert,
We should probably distinguish between what is wrapped in git-gui
(i.e. purely visual), and what is actually wrapped in the commit
message.
I believe the former is referred to as "soft wrap", while the latter
is "hard wrap
On Fri, Sep 06, 2019 at 11:24:12AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Sure, but wouldn't that similarly apply to fetching? What is it that
> > makes bursts of pushes more likely than bursts of fetches?
>
> Because people tend to use a repository as a gathering point? You
>
On Fri, Sep 06, 2019 at 02:13:26PM +0200, SZEDER Gábor wrote:
> Once upon a time GIT_TEST_HTTPD was a tristate variable and we
> exported 'GIT_TEST_HTTPD=YesPlease' in our CI scripts to make sure
> that we run the httpd tests in the Linux Clang and GCC build jobs, or
> error out if they can't be r
Jeff King writes:
> Sure, but wouldn't that similarly apply to fetching? What is it that
> makes bursts of pushes more likely than bursts of fetches?
Because people tend to use a repository as a gathering point? You
may periodically fetch from and push to a repository, and you may
even do so at
On Fri, Sep 06, 2019 at 01:00:40PM -0400, Derrick Stolee wrote:
> 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 go
On Fri, Sep 06, 2019 at 05:05:11PM +0200, René Scharfe wrote:
> > This approach seems to pretty reasonable. As somebody who's been
> > thinking about this, I'd be curious to hear your thoughts on:
> >
> > https://public-inbox.org/git/20190906065606.gc5...@sigill.intra.peff.net/
> >
> > which _in
On Fri, Sep 06, 2019 at 12:51:56PM -0400, Derrick Stolee wrote:
> > This one in theory benefits lots of other callsites, too, since it means
> > we'll actually return NULL instead of nonsense like "8". But grepping
> > around for calls to this function, I found literally zero of them
> > actually
On Fri, Sep 06, 2019 at 11:42:14AM -0400, Taylor Blau wrote:
> > > struct object_id *get_commit_tree_oid(const struct commit *commit)
> > > {
> > > - return &get_commit_tree(commit)->object.oid;
> > > + struct tree *tree = get_commit_tree(commit);
> > > + return tree ? &tree->object.oid : NULL;
On Fri, Sep 06, 2019 at 10:11:09AM -0700, Junio C Hamano wrote:
> > Is there even a single caller that is prepared to react to NULL?
> >
> > Answer. There is a single hit inside fsck.c that wants to report
> > an error without killing ourselves in fsck_commit_buffer(). I
> > however d
On Fri, Sep 06, 2019 at 09:57:29AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > This is sort-of attributable to my 834876630b (get_commit_tree(): return
> > NULL for broken tree, 2019-04-09). Before then it was a BUG(). However,
> > that state was relatively short-lived. Before 7b8a21d
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 +33,7 @@
>>> #define ALL_REV_FLAGS (((1u<<11)-1
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 +33,7 @@
>>> #define ALL_REV_FLAGS (((1u<<11)-1
Junio C Hamano writes:
> ...
> Is there even a single caller that is prepared to react to NULL?
>
> Answer. There is a single hit inside fsck.c that wants to report
> an error without killing ourselves in fsck_commit_buffer(). I
> however doubt its use of get_commit_tree() is correct
On Fri, Sep 06, 2019 at 09:59:04AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So far so good. But now imagine we call parse_commit_buffer() again, and
> > we re-parse. How does that interact with the half-parsed state? Some of
> > it works OK (e.g., lookup_tree() would find the same
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 +33,7 @@
> > #define ALL_REV_FLAGS (((1u<<11)-1) | NOT_USER_GIVEN | TRACK_LINEAR)
> >
> >
SZEDER Gábor writes:
> Once upon a time GIT_TEST_HTTPD was a tristate variable and we
> exported 'GIT_TEST_HTTPD=YesPlease' in our CI scripts to make sure
> that we run the httpd tests in the Linux Clang and GCC build jobs, or
> error out if they can't be run for any reason [1].
Wow. I vaguely
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
Jeff King writes:
> So far so good. But now imagine we call parse_commit_buffer() again, and
> we re-parse. How does that interact with the half-parsed state? Some of
> it works OK (e.g., lookup_tree() would find the same tree). Some not so
> much (I think we'd keep appending parents at each call
Jeff King writes:
> This is sort-of attributable to my 834876630b (get_commit_tree(): return
> NULL for broken tree, 2019-04-09). Before then it was a BUG(). However,
> that state was relatively short-lived. Before 7b8a21dba1 (commit-graph:
> lazy-load trees for commits, 2018-04-06), we'd have si
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 Fri, Sep 06, 2019 at 02:19:20AM -0400, 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))
> > di
Am 06.09.19 um 17:05 schrieb René Scharfe:
> A tag referencing an unknown object sounds strange to me. I imagine we
> might get such a thing when the referenced object is lost (broken repo)
> or purpose-built from an attacker. Could such a tag still be used for
> anything? Are there other possib
Am 06.09.19 um 09:13 schrieb Jeff King:
> On Thu, Sep 05, 2019 at 09:55:55PM +0200, René Scharfe wrote:
>
>> Add a function for accessing the ID of the object referenced by a tag
>> safely, i.e. without causing a segfault when encountering a broken tag
>> where ->tagged is NULL.
>
> This approach s
On 09/05, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Getting the lock for the index, refreshing it and then writing it is a
> > pattern that happens more than once throughout the codebase, and isn't
> > trivial to get right. Factor out the refresh_and_write_cache function
> > from bui
Hi Bert,
We should probably distinguish between what is wrapped in git-gui
(i.e. purely visual), and what is actually wrapped in the commit
message.
I believe the former is referred to as "soft wrap", while the latter
is "hard wrap".
On Thu, Sep 5, 2019 at 7:46 PM Bert Wesarg wrote:
> Please e
I've observed that when merging a branch, and there's a submodule
conflict, sometimes Git will prompt a suggested resolution like so:
```
Failed to merge submodule Core (not fast-forward)
Found a possible merge resolution for the submodule:
If this is correct simply add it to the index for exampl
Hi,
just to make it also clear in this thread: you can ignore this patch
series in favor of the better patch series by Peff [1] that has found
its way to the mailing list at the same time.
1.
https://public-inbox.org/git/20190905224859.ga28...@sigill.intra.peff.net/
Stephan
Once upon a time the GIT_SVN_TEST_HTTPD environment variable needed to
be set to enable SVN HTTP tests [1].
Then 3b072c577b (tests: replace test_tristate with "git env--helper",
2019-06-21) came along, and attempted to turn GIT_SVN_TEST_HTTPD into
a bool, but while doing so it mistyped the variabl
Once upon a time GIT_TEST_HTTPD was a tristate variable and we
exported 'GIT_TEST_HTTPD=YesPlease' in our CI scripts to make sure
that we run the httpd tests in the Linux Clang and GCC build jobs, or
error out if they can't be run for any reason [1].
Then 3b072c577b (tests: replace test_tristate w
I'm interested to mentor/help too, but I am definitely not a (some
people would even argue against "reliable") contributor but I might be
better than nothing and could pass my "lessons learned" along, so
hopefully next contributors are less of a pain to deal with than I am
Carlo
On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gábor wrote:
> To test 'git-p4' in the Linux Clang and GCC build jobs we used to
> install the 'p4' and 'p4d' binaries by directly downloading those
> binaries from a Perforce filehost. This has worked just fine ever
> since we started using Travis
To test 'git-p4' in the Linux Clang and GCC build jobs we used to
install the 'p4' and 'p4d' binaries by directly downloading those
binaries from a Perforce filehost. This has worked just fine ever
since we started using Travis CI [1], but during the last day or so
that filehost appeared to be gon
On Thu, Sep 05, 2019 at 09:55:55PM +0200, René Scharfe wrote:
> Add a function for accessing the ID of the object referenced by a tag
> safely, i.e. without causing a segfault when encountering a broken tag
> where ->tagged is NULL.
This approach seems to pretty reasonable. As somebody who's been
55 matches
Mail list logo
