Re: [PATCH] test-lib: add ability to cap the runtime of tests

On Mon, Jun 5, 2017 at 3:55 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Realistically I'm going to submit this patch, I'm not going to take >> the much bigger project of refactoring the entire test suite so that >> no test runs under N

What's cooking in git.git (Jun 2017, #03; Mon, 5)

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 branches, but I am still holding onto them. With many fixes accumulated since

Re: [PATCH 1/2] add setup step to filter-branch

Andreas Heiduk writes: > A specific `--setup` step in `git filter-branch` makes it much easier > to define the initial values of variables used in the real filters. > Also sourcing/defining utility functions here instead of > `--env-filter` improves performance and minimizes

Re: [PATCH] perf: work around the tested repo having an index.lock

Jeff King writes: > I don't really mind addressing this one case that much. I'm not sure > that we want to accrue a pile of band-aids here that causes a > maintenance burden and doesn't really solve the problem completely. One > way to do that is to say no to the first band-aid.

Re: [PATCH] perf: work around the tested repo having an index.lock

Christian Couder writes: > On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason writes: >> My feeling exactly. Diagnosing and failing upfront saying "well you made a copy but it is not

Re: [PATCH] test-lib: add ability to cap the runtime of tests

Ævar Arnfjörð Bjarmason writes: >> I certainly understand that but in the longer term, I'd prefer the >> approach to call out an overly large test. That will hopefully >> motivate us to split it (or speed up the thing) to help folks on >> many-core machines. > > The reason I

[ANNOUNCE] Git v2.13.1

The latest maintenance release Git v2.13.1 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.13.1' tag and the 'maint' branch that the tag points at: url =

Re: [PATCH v4 0/8] PCRE v2, PCRE v1 JIT, log -P & fixes

Ævar Arnfjörð Bjarmason writes: > On Fri, Jun 2, 2017 at 6:10 PM, Johannes Schindelin >> >> Will continue with testing Git for Windows using PCRE2 next week and keep >> you posted, > > Thanks a lot for testing it. Great to hear that it (definitely almost) works! > > If the grep

Re: New Order

Dear Sir, Have a nice day! We are interested in purchasing your products.Send your latest catalog and also, inform me about the Minimum order quantity, Delivery time or FOB, and payment terms warranty. Thanks and Best Regards, Mr.Marco Plujm. Phone: (+1) 703-684-5885 Fax: (+1) 703-684-0644

Re: Git Merge 2017 Videos

From: "Christian Couder" On Sun, Jun 4, 2017 at 7:36 PM, Kevin Daudt wrote: On Sun, Jun 04, 2017 at 11:24:17AM +0100, Philip Oakley wrote: While looking at the recent .gitignore issue (the need to use `**`) I came up against a comment in

Re: Git Merge 2017 Videos

On Sun, Jun 4, 2017 at 7:36 PM, Kevin Daudt wrote: > On Sun, Jun 04, 2017 at 11:24:17AM +0100, Philip Oakley wrote: >> While looking at the recent .gitignore issue (the need to use `**`) I came >> up against a comment in >>

Re: [PATCH] git-p4: remove obsolete version check

On Sat, Jun 03, 2017 at 06:55:22PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Sat, Jun 3, 2017 at 3:31 PM, Jakub Wilk wrote: > > The file is syntactically correct only in Python >= 2.6, so the > > version check never does anything. > > [CC-ing Eric who added that check] > >

Re: [PATCH 0/6] Some more git config completions

> As an aside from this series, has anyone ever proposed some method of > semi-automatically keeping this up-to-date? For configuration variables, not that I know of. For command line options, there was an attempt to enhance parse-options to dump all command line options and use this in the

Re: Git Merge 2017 Videos

On Sun, Jun 04, 2017 at 11:24:17AM +0100, Philip Oakley wrote: > While looking at the recent .gitignore issue (the need to use `**`) I came > up against a comment in > https://public-inbox.org/git/cagz79kzqsaubfotjyqm+-+ljyyec2ykj5exuy5kderezfh0...@mail.gmail.com/ > noting that the Git Merge 2017

Re: [PATCH] submodule foreach: correct $sm_path in nested submodules from a dir

On 03/06/17 15:07, Ramsay Jones wrote: [snip] >> diff --git a/Documentation/git-submodule.txt >> b/Documentation/git-submodule.txt >> index 74bc6200d5..52e3ef1325 100644 >> --- a/Documentation/git-submodule.txt >> +++ b/Documentation/git-submodule.txt >> @@ -218,20 +218,24 @@ information too.

Re: Git p4 sync changelist interval

On 4 June 2017 at 10:56, Андрей Ефанов <1134t...@gmail.com> wrote: > Hello, > > My goal is to sync the repository from p4 using an interval of > changelists so that the first changelist version of the repository > would be considered as an initial commit. > So I used the following command: > >

Re: [GSoC][PATCH v6 2/2] submodule: port subcommand foreach from shell to C

On Sat, Jun 3, 2017 at 7:43 AM, Stefan Beller wrote: > On Fri, Jun 2, 2017 at 4:24 AM, Prathamesh Chavan wrote: >> This aims to make git-submodule foreach a builtin. This is the very >> first step taken in this direction. Hence, 'foreach' is ported to >>

Git Merge 2017 Videos

While looking at the recent .gitignore issue (the need to use `**`) I came up against a comment in https://public-inbox.org/git/cagz79kzqsaubfotjyqm+-+ljyyec2ykj5exuy5kderezfh0...@mail.gmail.com/ noting that the Git Merge 2017 videos were not available at that time. Well, a search found them on

Git p4 sync changelist interval

Hello, My goal is to sync the repository from p4 using an interval of changelists so that the first changelist version of the repository would be considered as an initial commit. So I used the following command: git p4 clone //depot@cl1,cl2 And when it finished, the files, that were created

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 04, 2017 at 11:04:50AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > But I think a more compelling case is that there may be an ongoing > > operation in the original repo (e.g., say you are in the middle of > > writing a commit message) when we do a blind

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 04, 2017 at 09:00:28AM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > >> My feeling exactly. Diagnosing and failing upfront saying "well you > >> made a copy but it is not suitable for testing" sounds more sensible > >> at lesat to me. > > > >

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 04, 2017 at 09:55:15AM +0200, Ævar Arnfjörð Bjarmason wrote: > > Is a local clone really much slower these days? Wouldn't it is use > > hard links too? > > By the way the many properties that are preserved might not be worth > > preserving as they could make results depend a lot on

Re: [WIP/PATCH 7/6] perf: add a performance test for core.fsmonitor

On Sun, Jun 04, 2017 at 09:46:19AM +0200, Ævar Arnfjörð Bjarmason wrote: > What I'm referring to is not a limitation of git (we'll always be able > to turn off core.fsmonitor), but a limitation of the perf framework. > There's no way to run a test like this: > > ./run master next -- p*.sh >

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 4, 2017 at 9:37 AM, Christian Couder wrote: > On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason writes: >> My feeling exactly. Diagnosing and failing upfront saying "well you

Re: [WIP/PATCH 7/6] perf: add a performance test for core.fsmonitor

On Sun, Jun 4, 2017 at 3:59 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> This is WIP code for the reasons explained in the setup comments, >> unfortunately the perf code doesn't easily allow you to run different >> setup code for

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >>> My feeling exactly. Diagnosing and failing upfront saying "well you >>> made a copy but it is not suitable for testing" sounds more sensible >>> at lesat to me. >>

Re: [PATCH] test-lib: add ability to cap the runtime of tests

On Sun, Jun 4, 2017 at 2:31 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Speeding up the test suite by simply cataloging and skipping tests >> that take longer than N seconds is a hassle to maintain, and entirely >> skips some tests which