Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

On Wed, 23 May 2018, Junio C Hamano wrote: -> Accept-Encoding: gzip +> Accept-Encoding: ENCODINGS Is the ordering of these headers determined by the user of cURL library (i.e. Git), or whatever the version of cURL we happened to link with happens to produce? The point is whether the order

Re: [PATCH] t: make many tests depend less on the refs being files

On Mon, May 21, 2018 at 9:34 PM, Stefan Beller wrote: > On Sun, May 20, 2018 at 10:51 PM, Christian Couder > wrote: >> From: David Turner >> >> So that they work under alternate ref storage backends. > > Sometimes I have

Re: [PATCH] t: make many tests depend less on the refs being files

On Mon, May 21, 2018 at 1:49 PM, SZEDER Gábor wrote: >> > diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh >> > index 8f5c811dd7..c3b89ae783 100755 >> > --- a/t/t9903-bash-prompt.sh >> > +++ b/t/t9903-bash-prompt.sh >> > @@ -148,7 +148,7 @@ test_expect_success

[PATCH v2] t: make many tests depend less on the refs being files

From: David Turner Many tests are very focused on the file system representation of the loose and packed refs code. As there are plans to implement other ref storage systems, let's migrate these tests to a form that test the intent of the refs storage system instead of

Re: [PATCH] Add initial support for pax extended attributes

On Wed, May 23, 2018 at 11:34:52AM +0900, Junio C Hamano wrote: > > @@ -90,13 +99,32 @@ foreach my $tar_file (@ARGV) > > Z8 Z1 Z100 Z6 > > Z2 Z32 Z32 Z8 Z8 Z*', $_; > > } > > - next if $name =~ m{/\z}; > > $mode = oct

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

Jonathan Tan writes: > Makefile | 1 + > fetch-negotiator.c | 309 + > fetch-negotiator.h | 40 ++ > fetch-pack.c | 174 ++--- > object.h | 1 + > 5 files changed, 392

Re: [GSoC] A blog about 'git stash' project

On 21 May 2018 01:03:22 GMT+05:30, Paul-Sebastian Ungureanu wrote: > > I actually wrote a >short paragraph about one of them (the one regarding -p option) on the >blog (the first post). > That's interesting. I didn't realise that you wrote about one of the

Re: Why do we have both x*() and *_or_die() for "do or die"?

Ævar Arnfjörð Bjarmason writes: > Just a side-question unrelated to this patch per-se, why do we have both > x*() and *_or_die() functions in the codebase? I can't find any pattern > for one or the other. My understanding is that x*() were meant for system library functions.

Re: Officially supported Git versions

Patrick Lühne writes: > Is there an official list of the Git versions that are still actively > supported? Depends on your definition of "official". Distro with lts may patch older maintenance tracks longer than the upstream releases do, and as far as the normal end-users

Re: [PATCH] Add initial support for pax extended attributes

Pedro Alvarez writes: > From: Pedro Alvarez Piedehierro > Subject: [PATCH] Add initial support for pax extended attributes Lead it with the name of the area you are adding support for pax ext header, e.g. Subject: [PATCH] import-tars:

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

On Wed, May 23, 2018 at 10:23:26AM +0900, Junio C Hamano wrote: > Similarly, how much control do we have to ensure that the test HTTPD > server (1) supports gzip and (2) does not support encoding algos > with confusing names e.g. "funnygzipalgo" that may accidentally > match that pattern? I feel

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

Luke Diamand writes: >> However, instead of a separate patch, wouldn't it be better to squash >> it into the previous one? So 'make test' would succeed on every >> commit even with a newer p4 version. > > Junio? > > I can squash together the original commit and the two fixes

Re: should config options be treated as case-sensitive?

Ævar Arnfjörð Bjarmason writes: > The issues you note about the docs using foo.barbaz instead of > foo.barBaz should be fixed, but as noted in the "Syntax" section of > "git-config" we already document that the config keys are all > case-insensitive. We just like talking about

Re: [PATCH] Doc: Mention core.excludesFile in "man git-clean"

"Robert P. J. Day" writes: > Add a reference to the configuration setting "core.excludesFile" to > the man page for git-clean. > > Signed-off-by: Robert P. J. Day > > --- I understand that you are trying to reduce the source of the confusion you

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

Brandon Williams writes: > diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh > index f5721b4a5..913089b14 100755 > --- a/t/t5551-http-fetch-smart.sh > +++ b/t/t5551-http-fetch-smart.sh > @@ -26,14 +26,14 @@ setup_askpass_helper > cat >exp < > GET

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

Jonathan Tan writes: > I was thinking about fetch negotiation in some non-ideal situations > (specifically, when the client repo contains two or more independent > branches that meet only somewhere far in the past) and thought about > skipping over intermediate commits,

Re: [PATCH v5 0/4] unpack_trees_options: free messages when done

Martin Ågren writes: > (Maybe not to fix the leaking as such, but to keep 'maint' more up to > date with 'master' for easier merging of other topics?) I admit that I occasionally do such a "presumably no-op" merge to 'maint' out of sheer laziness, but in general I'd

Re: [PATCH v2] mailmap: update brian m. carlson's email address

On Tue, May 22, 2018 at 03:08:26PM -0700, Jonathan Nieder wrote: > These commits use author Brian M. Carlson . > Previously they matched > > brian m. carlson > > > but now they don't match any

Re: [PATCH 00/12] Die commit->util, die!

On Sat, May 12, 2018 at 1:00 AM, Nguyễn Thái Ngọc Duy wrote: > There's not much to write here. It's basically a copy from 12/12: > > This 'util' pointer can be used for many different purposes, > controlled in different ways. Some are not even contained in a command > code, but

Re: [PATCH] config: document value 2 for protocol.version

Brandon Williams wrote: > Update the config documentation to note the value `2` as an acceptable > value for the protocol.version config. > > Signed-off-by: Brandon Williams > --- > Documentation/config.txt | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Jonathan

[GSoC] Week 3 - 'git stash' blog

Hello, New week, new blog post [1]. Any feedback is greatly appreciated! Thank you! [1] https://ungps.github.io/ Best, Paul

[PATCH] config: document value 2 for protocol.version

Update the config documentation to note the value `2` as an acceptable value for the protocol.version config. Signed-off-by: Brandon Williams --- Documentation/config.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt

Proposal

Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Re: [PATCH v2] mailmap: update brian m. carlson's email address

Hi, brian m. carlson wrote: > An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to > individual persons", 2013-08-12), noted that there were two name > spellings and two email addresses and mapped the crustytoothpaste.net > address to the crustytoothpaste.ath.cx address. The

[GSoC][PATCH v2 4/4] rebase: remove -p code from git-rebase--interactive.sh

All the code specific to preserve-merges was moved to git-rebase--preserve-merges.sh, and so it’s useless to keep it here. Signed-off-by: Alban Gruin --- git-rebase--interactive.sh | 708 + 1 file changed, 8 insertions(+), 700

[GSoC][PATCH v2 3/4] rebase: use the new git-rebase--preserve-merges.sh

Creates a new type of rebase, "preserve-merges", used when rebase is called with -p. Before that, the type for preserve-merges was "interactive", and some places of this script compared $type to "interactive". Instead, the code now checks if $interactive_rebase is empty or not, as it is set to

[GSoC][PATCH v2 1/4] rebase: duplicate git-rebase--interactive.sh to git-rebase--preserve-merges.sh

This duplicates git-rebase--interactive.sh to git-rebase--preserve-merges.sh. This is done to split -p from -i. No modifications are made to this file here, but any code that is not used by -p will be stripped in the next commit. Signed-off-by: Alban Gruin --- .gitignore

[GSoC][PATCH v2 2/4] rebase: strip unused code in git-rebase--preserve-merges.sh

This removes the code coming from git-rebase--interactive.sh that is not needed by preserve-merges. Signed-off-by: Alban Gruin --- git-rebase--preserve-merges.sh | 65 +++--- 1 file changed, 4 insertions(+), 61 deletions(-) diff --git

[GSoC][PATCH v2 0/4] rebase: split rebase -p from rebase -i

This splits the `rebase --preserve-merges` functionnality from git-rebase--interactive.sh. All the dead code left by the duplication of git-rebase--interactive.sh is also removed. This will make it easier to rewrite this script in C. This patch series is based of js/sequencer-and-root-commits.

bug: --shallow-since misbehaves on old branch heads

Hi everybody, I think I have discovered a problem with clone/fetch --shallow-since: When a ref that is fetches has a head that is already older than the 'since' time, then the entire branch is fetched, instead of just the current commit. Repro: rm -rf tmp out deep git init tmp for i in

Re: [GSoC][PATCH 1/4] rebase: duplicate git-rebase--interactive.sh to git-rebase--preserve-merges.sh

Hi Stefan, Le 22/05/2018 à 20:26, Stefan Beller a écrit : > On Tue, May 22, 2018 at 6:31 AM, Alban Gruin wrote: >> This duplicates git-rebase--interactive.sh to >> git-rebase--preserve-merges.sh. This is done to split -p from -i. No >> modifications are made to this file

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

Hi Jonathan, > I wouldn't characterize the errors as "off by one errors". Yes, I put it in quotes but realized that would not convey it very well. > They are > more like...let me use a diagram: > > A > |\ > B D > | | > C E > > Suppose we know that the server does not have A, has C, and may or

Re: [PATCH v2 2/2] remote-curl: accept compressed responses with protocol v2

Brandon Williams wrote: > Configure curl to accept compressed responses when using protocol v2 by > setting `CURLOPT_ENCODING` to "", which indicates that curl should send > an "Accept-Encoding" header with all supported compression encodings. > > Signed-off-by: Brandon Williams

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

Brandon Williams wrote: > Configure curl to accept all encodings which curl supports instead of > only accepting gzip responses. > > This fixes an issue when using an installation of curl which is built > without the "zlib" feature. Since aa90b9697 (Enable info/refs gzip > decompression in HTTP

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

On Mon, 21 May 2018 15:57:18 -0700 Stefan Beller wrote: > In an ideal world, the server and client would both estimate the potential > reduction of the packfile to send, and base the decision if to continue > negotiating on the trade off if the packfile reduction savings are

[PATCH v2 1/2] remote-curl: accept all encodings supported by curl

Configure curl to accept all encodings which curl supports instead of only accepting gzip responses. This fixes an issue when using an installation of curl which is built without the "zlib" feature. Since aa90b9697 (Enable info/refs gzip decompression in HTTP client, 2012-09-19) we end up

[PATCH v2 2/2] remote-curl: accept compressed responses with protocol v2

Configure curl to accept compressed responses when using protocol v2 by setting `CURLOPT_ENCODING` to "", which indicates that curl should send an "Accept-Encoding" header with all supported compression encodings. Signed-off-by: Brandon Williams --- remote-curl.c | 1 + 1

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

On 05/22, Daniel Stenberg wrote: > On Mon, 21 May 2018, Jonathan Nieder wrote: > > > > Looking at the code here, this succeeds if enough memory is available. > > > There is no check if the given parameter is part of > > > Curl_all_content_encodings(); > > > > By "this" are you referring to the

Re: Why do we have both x*() and *_or_die() for "do or die"?

Duy Nguyen wrote: > On Tue, May 22, 2018 at 7:49 PM, Ævar Arnfjörð Bjarmason > wrote: >> Just a side-question unrelated to this patch per-se, why do we have both >> x*() and *_or_die() functions in the codebase? > > I wondered about that myself shortly after suggesting >

Re: [GSoC][PATCH 0/4] rebase: split rebase -p from rebase -i

On Tue, May 22, 2018 at 6:31 AM, Alban Gruin wrote: > This splits the `rebase --preserve-merges` functionnality from > git-rebase--interactive.sh. This is part of the effort to depreciate > preserve-merges. The new script, git-rebase--preserve-merges.sh, should be > left >

Re: [GSoC][PATCH 1/4] rebase: duplicate git-rebase--interactive.sh to git-rebase--preserve-merges.sh

On Tue, May 22, 2018 at 6:31 AM, Alban Gruin wrote: > This duplicates git-rebase--interactive.sh to > git-rebase--preserve-merges.sh. This is done to split -p from -i. No > modifications are made to this file here, but any code that is not used by -p > will be stripped in

Re: Why do we have both x*() and *_or_die() for "do or die"?

On Tue, May 22, 2018 at 10:49 AM, Ævar Arnfjörð Bjarmason wrote: > > On Wed, May 16 2018, Stefan Beller wrote: > >> A common pattern with the repo_read_index function is to die if the return >> of repo_read_index is negative. Move this pattern into a function. This was done

Re: Why do we have both x*() and *_or_die() for "do or die"?

On Tue, May 22, 2018 at 7:49 PM, Ævar Arnfjörð Bjarmason wrote: > > On Wed, May 16 2018, Stefan Beller wrote: > >> A common pattern with the repo_read_index function is to die if the return >> of repo_read_index is negative. Move this pattern into a function. > > Just a

Why do we have both x*() and *_or_die() for "do or die"?

On Wed, May 16 2018, Stefan Beller wrote: > A common pattern with the repo_read_index function is to die if the return > of repo_read_index is negative. Move this pattern into a function. Just a side-question unrelated to this patch per-se, why do we have both x*() and *_or_die() functions in

Officially supported Git versions

Hi, Is there an official list of the Git versions that are still actively supported? According to hearsay from colleagues, the latest five release series receive security patches. I can’t find a source for that, but might that be correct? There’s also the Wikipedia page on Git [1], but it

Re: should config options be treated as case-sensitive?

On Tue, 22 May 2018, Ævar Arnfjörð Bjarmason wrote: > > On Tue, May 22 2018, Robert P. J. Day wrote: > > > in my wanderings, more oddities, such as this: > > > > $ grep -ir blankboundary * > > builtin/blame.c:if (!strcmp(var, "blame.blankboundary")) { > >

Re: [PATCH 02/11] repository: introduce repo_read_index_or_die

On Mon, May 21, 2018 at 9:27 PM, Stefan Beller wrote: > Hi Brandon, > >>> One of the reviewers of the series questioned the overall goal of the >>> series as we want to move away from _die() in top level code but this >>> series moves more towards it. >> >> I've heard every

Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

On Tue, 22 May 2018, Suganthi wrote: We may not be able to upgrade to 7.60.0 any soon, Is the fix present in 7.45 , in this sequence of code. Please let me know. I don't know. I can't recall any SIGPIPE problems in recent days in libcurl, which is why I believe this problem doesn't exist

Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

We may not be able to upgrade to 7.60.0 any soon, Is the fix present in 7.45 , in this sequence of code. Please let me know. -- Sent from: http://git.661346.n2.nabble.com/

Re: user name

Thanks for the info, yes your are correct it was for the git config not github. I'm brand new to this and wasn't sure if a real name was required vs just a username. I know is some cases official names are required and didn't want to use the wrong one to start out with. I'm reading the help

Re: user name

On Tue, May 22, 2018 at 3:06 PM, Dennis Powless wrote: > Is it customary to use your real name or a user name when registering to GIT? I guess you are talking about using `git config --global user.name "XXX YYY"`. (Though maybe you are talking about github.com registration,

[GSoC][PATCH 2/4] rebase: strip unused code in git-rebase--preserve-merges.sh

This removes the code coming from git-rebase--interactive.sh that is not needed by preserve-merges. Signed-off-by: Alban Gruin --- git-rebase--preserve-merges.sh | 63 +++--- 1 file changed, 4 insertions(+), 59 deletions(-) diff --git

[GSoC][PATCH 1/4] rebase: duplicate git-rebase--interactive.sh to git-rebase--preserve-merges.sh

This duplicates git-rebase--interactive.sh to git-rebase--preserve-merges.sh. This is done to split -p from -i. No modifications are made to this file here, but any code that is not used by -p will be stripped in the next commit. Signed-off-by: Alban Gruin --- .gitignore

[GSoC][PATCH 4/4] rebase: remove -p code from git-rebase--interactive.sh

All the code specific to preserve-merges was moved to git-rebase--preserve-merges.sh, and so it’s useless to keep it here. Signed-off-by: Alban Gruin --- git-rebase--interactive.sh | 708 + 1 file changed, 8 insertions(+), 700

[GSoC][PATCH 3/4] rebase: use the new git-rebase--preserve-merges.sh

Creates a new type of rebase, "preserve-merges", used when rebase is called with -p. Before that, the type for preserve-merges was "interactive", and some places of this script compared $type to "interactive". Instead, the code now checks if $interactive_rebase is empty or not, as it is set to

[GSoC][PATCH 0/4] rebase: split rebase -p from rebase -i

This splits the `rebase --preserve-merges` functionnality from git-rebase--interactive.sh. This is part of the effort to depreciate preserve-merges. The new script, git-rebase--preserve-merges.sh, should be left to bitrot. All the dead code left by the duplication of git-rebase--interactive.sh is

user name

Is it customary to use your real name or a user name when registering to GIT? Dennis

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

On 22 May 2018 at 11:15, SZEDER Gábor wrote: > On Tue, May 22, 2018 at 10:41 AM, Luke Diamand wrote: >> SZEDER Gábor found that the unshelve tests fail with newer >> versions of Perforce (2016 vs 2015). >> >> The problem arises because when a file is added

Re: commit-graph: change in "best" merge-base when ambiguous

On 5/22/2018 1:39 AM, Michael Haggerty wrote: On 05/21/2018 08:10 PM, Derrick Stolee wrote: [...] In the Discussion section of the `git merge-base` docs [1], we have the following:     When the history involves criss-cross merges, there can be more than one best common ancestor for two

Re: should config options be treated as case-sensitive?

On Tue, May 22 2018, Robert P. J. Day wrote: > in my wanderings, more oddities, such as this: > > $ grep -ir blankboundary * > builtin/blame.c: if (!strcmp(var, "blame.blankboundary")) { > Documentation/config.txt:blame.blankBoundary:: > Documentation/blame-options.txt: be controlled

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Tue, May 08 2018, Jeff King wrote: > On Mon, May 07, 2018 at 03:24:59PM -0700, Stefan Beller wrote: > >> Hence I propose "git range-diff", similar to topic-diff, that >> was proposed earlier. >> >> * it "diffs ranges" of commits. >> * it can also deal with out-of-git things like patch series,

Re: [PATCH v5 0/4] unpack_trees_options: free messages when done

On 22 May 2018 at 04:54, Junio C Hamano wrote: > Junio C Hamano writes: >> Hmph, this unfortunately depends on 'next', which means we cannot >> merge it down to 'maint' later to fix these leaks. I guess it is >> not a huge deal, though. We've lived with

Re: [PATCH] regex: do not call `regfree()` if compilation fails

On 22 May 2018 at 04:20, Eric Sunshine wrote: > On Mon, May 21, 2018 at 2:43 PM, Stefan Beller wrote: >> On Sun, May 20, 2018 at 3:50 AM, Martin Ågren wrote: >>> It is apparently undefined behavior to call `regfree()` on a

Re: symbol string_list_appendf() unused

Hi Ramsay On 22 May 2018 at 02:08, Ramsay Jones wrote: > On 22/05/18 00:59, Junio C Hamano wrote: >> There is a reroll by Martin that ties all the loose ends. > > Ah, OK, sorry for the noise. No worry. Thanks for pointing out the unused function to me. I appreciate

Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

On Tue, 22 May 2018, curlUser wrote: Again SIGPIPE is seen with curl version 7.45.0 with multi interface. Backtrace shows : ... Looks like SIGPIPE_IGNORE to be added in prune_dead connections or in disconnect_if_dead? Can anyone comment on this. I'm pretty sure this issue isn't present in

Re: [curl PATCH 2/2] ignore SIGPIPE during curl_multi_cleanup

Hi, Again SIGPIPE is seen with curl version 7.45.0 with multi interface. Backtrace shows : #7 0x7f141bea40cd in Curl_ossl_close (conn=0x7f14193f9848, sockindex=0) at vtls/openssl.c:881 #8 0x7f141bea8f54 in Curl_ssl_close (conn=0x7f14193f9848, sockindex=0) at vtls/vtls.c:527 #9

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

On Tue, May 22, 2018 at 10:41 AM, Luke Diamand wrote: > SZEDER Gábor found that the unshelve tests fail with newer > versions of Perforce (2016 vs 2015). > > The problem arises because when a file is added in a P4 > shelved changelist, the depot revision is shown as "none" > if

[PATCH] Add initial support for pax extended attributes

From: Pedro Alvarez Piedehierro Sometimes the tar files will contain pax extended attributes to deal with cases where the information needed doesn't fit in a standard ustar entry. One of these cases is when the path is larger than 100 characters. A pax entry will appear

[PATCH 0/1] git-p4: unshelving: fix problem with newer P4

This fixes a problem found by SZEDER Gábor with newer versions of the Perforce database engine (2016 onwards). It looks like the behaviour has change subtly when reporting the revision of newly added files. The fix is to just use the file status. Luke Diamand (1): git-p4: unshelve: use

[PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

SZEDER Gábor found that the unshelve tests fail with newer versions of Perforce (2016 vs 2015). The problem arises because when a file is added in a P4 shelved changelist, the depot revision is shown as "none" if using the older p4d (which makes sense - the file doesn't yet exist, so can't have a

should config options be treated as case-sensitive?

in my wanderings, more oddities, such as this: $ grep -ir blankboundary * builtin/blame.c:if (!strcmp(var, "blame.blankboundary")) { Documentation/config.txt:blame.blankBoundary:: Documentation/blame-options.txt:be controlled via the `blame.blankboundary` config option.

[PATCH] Doc: Mention core.excludesFile in "man git-clean"

Add a reference to the configuration setting "core.excludesFile" to the man page for git-clean. Signed-off-by: Robert P. J. Day --- diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index 03056dad0..449cbc2af 100644 --- a/Documentation/git-clean.txt

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

On Mon, 21 May 2018, Jonathan Nieder wrote: Looking at the code here, this succeeds if enough memory is available. There is no check if the given parameter is part of Curl_all_content_encodings(); By "this" are you referring to the preimage or the postimage? Are you suggesting a change in