On Sat, Dec 23, 2017 at 05:44:00PM +, Ævar Arnfjörð Bjarmason wrote:
> The reason to do this is to be able to use features released with perl
> in the last decade, 5.10 was a major feature release including things
> like new regex features, state variables, the defined-or operator
> etc.[3]
>
Hi Carl,
On Sat, 23 Dec 2017, Carl Baldwin wrote:
> I imagine that a "git commit --amend" would also insert a "replaces"
> reference to the original commit but I failed to mention that in my
> original post.
And cherry-pick, too, of course.
Both of these examples hint at a rather huge urge of
Hi Vadim,
thank you for your contribution!
On Sun, 24 Dec 2017, Vadim Petrov wrote:
> I suppose that if the condition is fulfilled then the previously
> obtained value will not be necessary.
I have to be honest: this commit message (including the subject) left me
quite puzzled as to the intent
Hi Ævar,
On Sat, 23 Dec 2017, Ævar Arnfjörð Bjarmason wrote:
> On Sat, Dec 23 2017, Carl Baldwin jotted:
>
> > The big contention among git users is whether to rebase or to merge
> > changes [2][3] while iterating. I used to firmly believe that merging
> > was the way to go and rebase was
On December 23, 2017 4:02 PM, Carl Baldwin wrote:
> On Sat, Dec 23, 2017 at 07:59:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I think this is a worthwhile thing to implement, there are certainly
> > use-cases where you'd like to have your cake & eat it too as it were,
> > i.e. have a nice
On Sat, Dec 23 2017, Carl Baldwin jotted:
> On Sat, Dec 23, 2017 at 07:59:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> I think this is a worthwhile thing to implement, there are certainly
>> use-cases where you'd like to have your cake & eat it too as it were,
>> i.e. have a nice rebased
Remove the unused fnmatch() test parameter from the wildmatch
test. The code that used to test this was removed in 70a8fc999d ("stop
using fnmatch (either native or compat)", 2014-02-15).
As a --word-diff shows the only change to the body of the tests is the
removal of the second out of four
There has never been any full roundtrip testing of what git-ls-files
and other functions that use wildmatch() actually do, rather we've
been satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's
Rewrite the wildmatch() test suite so that each test now tests all
combinations of the wildmatch() WM_CASEFOLD and WM_PATHNAME flags.
Before this change some test inputs were not tested on
e.g. WM_PATHNAME. Now the function is stress tested on all possible
inputs, and for each input we declare
Use a pattern from the nul_match() function in t7008-grep-binary.sh to
make sure that we don't just fall through to the "else" if there's an
unknown parameter.
This is something I added in commit 77f6f4406f ("grep: add a test
helper function for less verbose -f \0 tests", 2017-05-20) to grep
Change the wildmatch test to use more standard shell style, usually we
use "if test" not "if [".
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t3070-wildmatch.sh | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/t/t3070-wildmatch.sh
This increases the test coverage we have for wildmatch, and hopefully
doesn't break anything, but see the fantastic hack that is 6/6 and
form your own opinion.
The backstory of this is that back in June I posted an RFC series here
to the list to refactor wildmatch() itself to no-op support
Replace the 4-width mixed space & tab indentation in this file with
indentation with tabs as we do in most of the rest of our tests.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t3070-wildmatch.sh | 54 ++--
1 file changed, 27
On Sat, Dec 23, 2017 at 07:59:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
> I think this is a worthwhile thing to implement, there are certainly
> use-cases where you'd like to have your cake & eat it too as it were,
> i.e. have a nice rebased history in "git log", but also have the "raw"
> history
I suppose that if the condition is fulfilled then the previously
obtained value will not be necessary.
Signed-off-by: Vadim Petrov
---
setup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/setup.c b/setup.c
index 8cc34186c..1ce0189fa 100644
---
On Sat, Dec 23 2017, Carl Baldwin jotted:
> The big contention among git users is whether to rebase or to merge
> changes [2][3] while iterating. I used to firmly believe that merging
> was the way to go and rebase was harmful. More recently, I have worked
> in some environments where I saw
On December 23, 2017 12:44 PM, Ævar Arnfjörð Bjarmason wrote:
>
> In late 2010 I bumped our perl version dependency from 5.6.* to 5.8.0[1]. Git
> had been failing for a while on <5.8, and it was suspected that nobody cared
> enough to keep using it, which turned out to be true.
>
> Follow that
On Sat, Dec 23 2017, Wei Shuyu jotted:
> Git has been taught to support an https:// used for http.proxy when
> using recent versions of libcurl.
>
> To use https proxy with self-signed certs, we need a way to
> unset CURLOPT_PROXY_SSL_VERIFYPEER and CURLOPT_PROXY_SSL_VERIFYHOST
> just like
In late 2010 I bumped our perl version dependency from 5.6.* to
5.8.0[1]. Git had been failing for a while on <5.8, and it was
suspected that nobody cared enough to keep using it, which turned out
to be true.
Follow that up with bumping the dependency to 5.10.0. The 5.8.0
release was released in
--
Compliment of the day , I am a professional banker with International
and Qualified Experience. Please i seek your Urgent Attention and
Cooperation to transfer the sum of $8.5M into your account. Risk free
and Beneficial. Waiting response so that we can proceed to the next
Git has been taught to support an https:// used for http.proxy when
using recent versions of libcurl.
To use https proxy with self-signed certs, we need a way to
unset CURLOPT_PROXY_SSL_VERIFYPEER and CURLOPT_PROXY_SSL_VERIFYHOST
just like direct SSL connection. This is required if we want
use
On Fri, Dec 15, 2017 at 8:25 PM, Junio C Hamano wrote:
> I think the code makes sense, but it won't be understandable by
> those who do not know what you discussed in the original thread.
>
> A proper commit log message, with a new test or two in t6120, would
> be an
On Sun, Dec 3, 2017 at 1:25 AM, Philip Oakley wrote:
> From: "anatoly techtonik"
>
> comment at end - Philip
>
>
> On Fri, Nov 24, 2017 at 1:24 PM, Ævar Arnfjörð Bjarmason
> wrote:
>>
>> On Fri, Nov 24, 2017 at 10:52 AM, anatoly
On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano wrote:
> Igor Djordjevic writes:
>
>> If you would like to mimic output of "git show-ref", repeating
>> commits for each tag pointing to it and showing full tag name as
>> well, you could do something
GREETINGS,
I AM BORTE ,I WAS DIAGNOSE OF OVARIAN CANCER,WHICH DOCTORS HAVE
CONFIRMED THAT I HAVE ONLY FEW WEEKS TO LIVE, SO I HAVE DECIDED TO
DONATE EVERYTHING I HAVE TO THE ORPHANAGE AND THE POOR WIDOWS THROUGH
YOU .PLEASE KINDLY REPLY ME ONLY ON MY EMAIL ADDRES HERE
On Fri, Dec 22 2017, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> I don't agree that git as a tool should be so opinionated. You can edit
>> these --fixup messages right now with --edit, and I do. That it doesn't
>> work with -m"" as it should is a
Basically somehow at the point when I investigated stuff on the usb
stick I found the repository at the top level of the usb folder
hierarchy. Therefore git got confused by what I was doing at
usb_subfolder which is lower in the folder hierarchy and that is way
it was having amasement inducing
On Mon, Dec 18, 2017 at 08:12:49AM -0500, Jeff King wrote:
> On Mon, Dec 18, 2017 at 11:13:34AM +0100, Torsten Bögershausen wrote:
>
> > Just to confirm my missing knowledge here:
> > Does this mean, that git-gui and gitk can decode/reencode
> > the content of a file/blob, when the .gitattributes
28 matches
Mail list logo