On Mon, Jun 5, 2017 at 4:02 AM, Junio C Hamano wrote:
> 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 suitable
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 second, and of course any such refactori
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
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 clogging the output
>
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.
Yup, that was w
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 suitable for testing" sounds more sensible
at lesat to me.
>>>
>>>
Æ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 didn't document this
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 = https://kern
Æ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 tests it's very li
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
Wash
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
https://public-inbox.org/git/cagz79kzqsaubfotjyqm+-+lj
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
>> https://public-inbox.org/git/cagz79kzqsaubfotjyqm+-+ljyyec2ykj5exuy5kderez
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]
>
> Your commit message d
> 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
compl
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 v
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.
>
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:
>
> git
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
>> submodule--helper, and submodule--helper i
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
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 bef
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 copy of the filesys
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.
> >
> > This change makes t
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 the
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
>
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
made a copy but it is not suitable for testing" sounds more sensibl
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 different versions you're testing. This test w
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.
>>
>> This change makes the repo suitable
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 would be nice to at least partially r
28 matches
Mail list logo
