Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

2017-12-23 Thread brian m. carlson
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] >

Re: Bring together merge and rebase

2017-12-23 Thread Johannes Schindelin
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

Re: [PATCH] setup.c: move statement under condition

2017-12-23 Thread Johannes Schindelin
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

Re: Bring together merge and rebase

2017-12-23 Thread Johannes Schindelin
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

RE: Bring together merge and rebase

2017-12-23 Thread Randall S. Becker
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

Re: Bring together merge and rebase

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

[PATCH 4/6] wildmatch test: remove dead fnmatch() test code

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

[PATCH 6/6] wildmatch test: create & test files on disk in addition to in-memory

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

[PATCH 5/6] wildmatch test: perform all tests under all wildmatch() modes

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

[PATCH 3/6] wildmatch test: use a paranoia pattern from nul_match()

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

[PATCH 2/6] wildmatch test: use more standard shell style

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

[PATCH 0/6] increase wildmatch test coverage

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

[PATCH 1/6] wildmatch test: indent with tabs, not spaces

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

Re: Bring together merge and rebase

2017-12-23 Thread Carl Baldwin
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

[PATCH] setup.c: move statement under condition

2017-12-23 Thread Vadim Petrov
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 ---

Re: Bring together merge and rebase

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

RE: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

2017-12-23 Thread Randall S. Becker
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

Re: [RFC PATCH v2] http: support CURLPROXY_HTTPS

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

[RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

2017-12-23 Thread Kabore Zongo
-- 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

[RFC PATCH v2] http: support CURLPROXY_HTTPS

2017-12-23 Thread Wei Shuyu
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

[RFC] Prepend "tags/" when describing tags with embedded name

2017-12-23 Thread Daniel Knittl-Frank
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

Re: Re: Unify annotated and non-annotated tags

2017-12-23 Thread anatoly techtonik
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

Re: Unify annotated and non-annotated tags

2017-12-23 Thread anatoly techtonik
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,

2017-12-23 Thread mis.sbort...@ono.com
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

Re: [PATCH v2 2/2] commit: add support for --fixup -m""

2017-12-23 Thread Ævar Arnfjörð Bjarmason
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

Re: Usability outrage as far as I am concerned

2017-12-23 Thread Cristian Achim
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

Re: [PATCH v1] convert: add support for 'encoding' attribute

2017-12-23 Thread Torsten Bögershausen
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