On Fri, Apr 15, 2016 at 4:51 PM, Duy Nguyen wrote:
> Numbers are encouraging though. On linux-2.6 repo running on linux and
> ext4 filesystem, checkout_paths() would dominate "git checkout :/".
> Unmodified git takes about 31s.
>
>
> 16:26:00.114029 builtin/checkout.c:1299 performance: 31.18497365
Hi Lars,
On Sun, 24 Apr 2016, Lars Schneider wrote:
> [...] the current Git Travis CI OSX build always installs the latest
> versions of Git LFS and Perforce via brew [1] and the Linux build
> installs fixed versions [2]. Consequently new LFS/Perforce versions can
> brake the OS X build even if
Hi Luk,
On Sun, 24 Apr 2016, Luke Diamand wrote:
> On 24 Apr 2016 08:19, "Johannes Schindelin"
> wrote:
> >
> > Hi Lars & Junio,
> >
> > On Fri, 22 Apr 2016, Junio C Hamano wrote:
> >
> > > Lars Schneider writes:
> > >
> > > > Thanks for the explanation. My intention was not to be offensive.
>
Hi Gábor,
On Sun, 24 Apr 2016, SZEDER Gábor wrote:
> > > Don't worry; I didn't feel offended. The Travis stuff running on
> > > the branches at http://github.com/git/git would surely catch issues
> > > on MacOSX and/or around git-p4 (neither of which I test myself when
> > > merging to 'pu') bef
> > Don't worry; I didn't feel offended. The Travis stuff running on
> > the branches at http://github.com/git/git would surely catch issues
> > on MacOSX and/or around git-p4 (neither of which I test myself when
> > merging to 'pu') before they hit 'next', and that is already helping
> > us grea
Hi Lars & Junio,
On Fri, 22 Apr 2016, Junio C Hamano wrote:
> Lars Schneider writes:
>
> > Thanks for the explanation. My intention was not to be offensive.
> > I was curious about your workflow and I was wondering if the
> > Travis CI integration could be useful for you in any way.
>
> Don't
Lars Schneider writes:
> Thanks for the explanation. My intention was not to be offensive.
> I was curious about your workflow and I was wondering if the
> Travis CI integration could be useful for you in any way.
Don't worry; I didn't feel offended. The Travis stuff running on
the branches at
> On 16 Apr 2016, at 20:02, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> Also this would incur wait time on Junios side
>>>
>>> 1) collect patches (many series over the day)
>>> 2) push
>>> 3) wait
>>> 4) do the merges
>> He could do the merges as he does them today but after some t
Lars Schneider writes:
>> Also this would incur wait time on Junios side
>>
>> 1) collect patches (many series over the day)
>> 2) push
>> 3) wait
>> 4) do the merges
> He could do the merges as he does them today but after some time
> he (and the contributor of a patch) would know if a certain
On 13 Apr 2016, at 19:29, Stefan Beller wrote:
> On Wed, Apr 13, 2016 at 10:09 AM, Lars Schneider
> wrote:
>>
>>> On 13 Apr 2016, at 18:27, Junio C Hamano wrote:
>>>
>>> Lars Schneider writes:
>>>
@Junio:
If you setup Travis CI for your https://github.com/gitster/git fork
th
On 04/15/2016 06:52 PM, Jeff King wrote:
> On Fri, Apr 15, 2016 at 01:18:46PM +0200, Christian Couder wrote:
>
>> On Fri, Apr 15, 2016 at 11:51 AM, Duy Nguyen wrote:
>>> On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:
There is a draft of an article about the first part
On Fri, Apr 15, 2016 at 10:08 PM, Stefan Beller wrote:
> On Fri, Apr 15, 2016 at 2:51 AM, Duy Nguyen wrote:
>> On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:
>> The idea is simple, you offload some work to process workers. In this
>> patch, only entry.c:write_entry() is moved t
On Fri, Apr 15, 2016 at 10:31:39AM -0700, Junio C Hamano wrote:
> Last time I checked, I think the accesses to attributes from the
> convert.c thing was one of the things that are cumbersome to make
> safe in multi-threaded world.
Multi-threaded grep has the same problem. I think we started with
Jeff King writes:
> On Fri, Apr 15, 2016 at 01:18:46PM +0200, Christian Couder wrote:
>
>> On Fri, Apr 15, 2016 at 11:51 AM, Duy Nguyen wrote:
>> > On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:
>> >>
>> >> There is a draft of an article about the first part of the Contributor
On Fri, Apr 15, 2016 at 01:18:46PM +0200, Christian Couder wrote:
> On Fri, Apr 15, 2016 at 11:51 AM, Duy Nguyen wrote:
> > On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:
> >>
> >> There is a draft of an article about the first part of the Contributor
> >> Summit in the draft o
On Fri, Apr 15, 2016 at 2:51 AM, Duy Nguyen wrote:
> On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:
>> On Tue, Apr 12, 2016 at 4:59 PM, Stefan Beller wrote:
>> > On Tue, Apr 12, 2016 at 2:42 AM, Duy Nguyen wrote:
>> >>> On Mon, Apr 11, 2016 at 7:51 AM, Stefan Beller
>> >>> w
On Fri, Apr 15, 2016 at 6:18 PM, Christian Couder
wrote:
> On Fri, Apr 15, 2016 at 11:51 AM, Duy Nguyen wrote:
>> On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:
>>>
>>> There is a draft of an article about the first part of the Contributor
>>> Summit in the draft of the next Gi
On Fri, Apr 15, 2016 at 11:51 AM, Duy Nguyen wrote:
> On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:
>>
>> There is a draft of an article about the first part of the Contributor
>> Summit in the draft of the next Git Rev News edition:
>>
>> https://github.com/git/git.github.io/b
On Fri, Apr 15, 2016 at 12:04:49AM +0200, Christian Couder wrote:
> On Tue, Apr 12, 2016 at 4:59 PM, Stefan Beller wrote:
> > On Tue, Apr 12, 2016 at 2:42 AM, Duy Nguyen wrote:
> >>> On Mon, Apr 11, 2016 at 7:51 AM, Stefan Beller wrote:
> Hi Greg,
>
> Thanks for your talk at the G
On Tue, Apr 12, 2016 at 4:59 PM, Stefan Beller wrote:
> On Tue, Apr 12, 2016 at 2:42 AM, Duy Nguyen wrote:
>>> On Mon, Apr 11, 2016 at 7:51 AM, Stefan Beller wrote:
Hi Greg,
Thanks for your talk at the Git Merge 2016!
>>
>> Huh? It already happened?? Any interesting summary to sha
Lars Schneider writes:
> I am not sure what you mean by "fail to hit 'pu'". Maybe we talk at
> cross purposes. Here is what I think you do, please correct me:
>
> 1.) You pick the topics from the mailing list and create feature
> branches for each one of them. E.g. one of my recent topics
>
On Wed, Apr 13, 2016 at 10:29:57AM -0700, Stefan Beller wrote:
>
> At Git Merge Greg said (paraphrasing here):
>
> We waste developers time, because we have plenty of it. Maintainers time
> however is precious because maintainers are the bottleneck and a scare
> resource to come by.
s/scar
On Wed, Apr 13, 2016 at 10:09 AM, Lars Schneider
wrote:
>
>> On 13 Apr 2016, at 18:27, Junio C Hamano wrote:
>>
>> Lars Schneider writes:
>>
>>> @Junio:
>>> If you setup Travis CI for your https://github.com/gitster/git fork
>>> then Travis CI would build all your topic branches and you (and
>>>
> On 13 Apr 2016, at 18:27, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> @Junio:
>> If you setup Travis CI for your https://github.com/gitster/git fork
>> then Travis CI would build all your topic branches and you (and
>> everyone who is interested) could check
>> https://travis-ci.
Lars Schneider writes:
> @Junio:
> If you setup Travis CI for your https://github.com/gitster/git fork
> then Travis CI would build all your topic branches and you (and
> everyone who is interested) could check
> https://travis-ci.org/gitster/git/branches to see which branches
> will break pu
Matthieu Moy writes:
True, presumably the Travis integration already solves that part, so
I suspect it is just the matter of setting up:
- a fork of git.git and have Travis monitor any and all new
branches;
- a bot that scans the list traffic, applies each s
> On 13 Apr 2016, at 14:30, Matthieu Moy wrote:
>
> Lars Schneider writes:
>
>>> On 13 Apr 2016, at 07:43, Matthieu Moy wrote:
>>>
>>> Junio C Hamano writes:
>>>
Matthieu Moy writes:
True, presumably the Travis integration already solves that part, so
I suspect it is
> > I don't know how 0 bot solves this, but the obvious issue with this
> > approach is to allow dealing with someone sending a patch like
> >
> > +++ Makefile
> > --- Makefile
> > +all:
> > + rm -fr $(HOME); sudo rm -fr /
> >
> > to the list. One thing that Travis gives us for free is isolation:
Lars Schneider writes:
>> On 13 Apr 2016, at 07:43, Matthieu Moy wrote:
>>
>> Junio C Hamano writes:
>>
>>> Matthieu Moy writes:
>>>
>>> True, presumably the Travis integration already solves that part, so
>>> I suspect it is just the matter of setting up:
>>>
>>> - a fork of git.git and h
> On 13 Apr 2016, at 07:43, Matthieu Moy wrote:
>
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>> True, presumably the Travis integration already solves that part, so
>> I suspect it is just the matter of setting up:
>>
>> - a fork of git.git and have Travis monitor any and all new
On 12 Apr 2016, at 22:49, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> But my point wasn't to say "we already have everything we need", but
>> rather "we already have part of the solution, so an ideal complete
>> solution could integrate with it".
>
> Yes. That is a good direction to go
Junio C Hamano writes:
> Matthieu Moy writes:
>
> True, presumably the Travis integration already solves that part, so
> I suspect it is just the matter of setting up:
>
> - a fork of git.git and have Travis monitor any and all new
>branches;
>
> - a bot that scans the list traffic, applie
Matthieu Moy writes:
> But my point wasn't to say "we already have everything we need", but
> rather "we already have part of the solution, so an ideal complete
> solution could integrate with it".
Yes. That is a good direction to go.
They may already have part of the solution, and their half
Stefan Beller writes:
> On Tue, Apr 12, 2016 at 12:23 AM, Matthieu Moy
> wrote:
>> Stefan Beller writes:
>>
>>> Hi Greg,
>>>
>>> Thanks for your talk at the Git Merge 2016!
>>> The Git community uses the same workflow as the kernel. So we may be
>>> interested in the 0 bot which could compile a
On Tue, Apr 12, 2016 at 07:52:02AM -0700, Stefan Beller wrote:
> On Tue, Apr 12, 2016 at 12:23 AM, Matthieu Moy
> wrote:
> > Stefan Beller writes:
> >
> >> Hi Greg,
> >>
> >> Thanks for your talk at the Git Merge 2016!
> >> The Git community uses the same workflow as the kernel. So we may be
> >>
On Tue, Apr 12, 2016 at 2:42 AM, Duy Nguyen wrote:
>> On Mon, Apr 11, 2016 at 7:51 AM, Stefan Beller wrote:
>>> Hi Greg,
>>>
>>> Thanks for your talk at the Git Merge 2016!
>
> Huh? It already happened?? Any interesting summary to share with us?
Summary from the contributors summit:
* encoding w
On Tue, Apr 12, 2016 at 12:23 AM, Matthieu Moy
wrote:
> Stefan Beller writes:
>
>> Hi Greg,
>>
>> Thanks for your talk at the Git Merge 2016!
>> The Git community uses the same workflow as the kernel. So we may be
>> interested in the 0 bot which could compile and test each patch on the list.
>
>
> On Mon, Apr 11, 2016 at 7:51 AM, Stefan Beller wrote:
>> Hi Greg,
>>
>> Thanks for your talk at the Git Merge 2016!
Huh? It already happened?? Any interesting summary to share with us?
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord..
Stefan Beller writes:
> Hi Greg,
>
> Thanks for your talk at the Git Merge 2016!
> The Git community uses the same workflow as the kernel. So we may be
> interested in the 0 bot which could compile and test each patch on the list.
In the case of Git, we already have Travis-CI that can do rather
On Mon, Apr 11, 2016 at 09:29:59PM -0700, Stefan Beller wrote:
> Resending as plain text. (I need to tame my mobile)
>
> On Mon, Apr 11, 2016 at 7:51 AM, Stefan Beller wrote:
> > Hi Greg,
> >
> > Thanks for your talk at the Git Merge 2016!
> > The Git community uses the same workflow as the kerne
Resending as plain text. (I need to tame my mobile)
On Mon, Apr 11, 2016 at 7:51 AM, Stefan Beller wrote:
> Hi Greg,
>
> Thanks for your talk at the Git Merge 2016!
> The Git community uses the same workflow as the kernel. So we may be
> interested in the 0 bot which could compile and test each p
41 matches
Mail list logo
