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
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
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
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
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
Jonathan Tan writes:
> Makefile | 1 +
> fetch-negotiator.c | 309 +
> fetch-negotiator.h | 40 ++
> fetch-pack.c | 174 ++---
> object.h | 1 +
> 5 files changed, 392
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
Æ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.
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
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:
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
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
Æ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
"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
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
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,
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
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
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
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
Hello,
New week, new blog post [1]. Any feedback is greatly appreciated! Thank you!
[1]
https://ungps.github.io/
Best,
Paul
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
>
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
>
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
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
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
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
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
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")) {
> >
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
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
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/
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
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,
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
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
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
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
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
Is it customary to use your real name or a user name when registering to GIT?
Dennis
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
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
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
73 matches
Mail list logo