On Thu, Jun 7, 2018 at 1:48 AM Jonathan Nieder wrote:
> Whatever
> I try, I end up with one of two results: either it uses zsh's standard
> completion, or it spews a stream of errors about missing functions
> like compgen. What am I doing wrong?
Try adding to the top of your .zshrc:
autoload -U
Unrecognized escape sequences are invalid in values:
$ git config -f - --list <
---
Documentation/config.txt | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b18c0f97fe..f772186c44 100644
--- a/Documentati
On Tue, Aug 1, 2017 at 10:38 PM, Shawn Pearce wrote:
>> Peff and I discussed off-list whether the lookup-by-SHA-1 feature is
>> so important in the first place. Currently, all references must be
>> scanned for the advertisement anyway,
>
> Not really. You can hide refs and allow-tip-sha1 so client
On Sun, Jul 30, 2017 at 11:51 PM, Shawn Pearce wrote:
> - Ref-like files (FETCH_HEAD, MERGE_HEAD) also use type 0x3.
> - Combine reflog storage with ref storage for small transactions.
> - Separate reflog storage for base refs and historical logs.
How is the stash implemented in reftable? In par
On Sun, Jul 30, 2017 at 11:51 PM, Shawn Pearce wrote:
> - Near constant time verification a SHA-1 is referred to by at least
> one reference (for allow-tip-sha1-in-want).
I think I understated the importance of this when I originally brought
up allow-tip-sha1-in-want. This is an important optim
On Sun, Jul 16, 2017 at 3:43 PM, Shawn Pearce wrote:
> True... but... in my "android" example repository we have 866,456 live
> refs. A block size of 64k needs only 443 blocks, and a 12k index, to
> get the file to compress to 28M (vs. 62M packed-refs).
>
> Index records are averaging 28 bytes per
On Thu, Jul 13, 2017 at 8:11 PM, Shawn Pearce wrote:
> In another (Gerrit Code Review), we disable reflogs for
> the insane refs/changes/ namespace, as nearly every reference is
> created once, and never modified.
Apologies for the tangent, but this is not true in the most recent
Gerrit implement
On Tue, Dec 22, 2015 at 7:39 AM, Paul Smith wrote:
> I'm trying to build Git (2.6.4) on GNU/Linux, but without any
> requirements (other than basic libc etc.) on the local system. This
> works fine except for one thing: git-remote-https.
>
> In order to build this I need to have libcurl, but libc
On Tue, Dec 22, 2015 at 8:11 AM, Shawn Pearce wrote:
> Yup, and Gerrit Code Review servers often have 100k+ refs per
> repository. We can't rewrite the entire store every time either. So
> its not a flat list. Its a directory structure using the / separators
> in the ref namespace.
I wonder if th
On Tue, Dec 1, 2015 at 3:55 PM, Jonathan Nieder wrote:
> Cc-ing dborowitz, who has been working on storing Gerrit's code review
> information in Git instead of a separate database (e.g., see [1]).
Thanks, we actually already had a thread going that I realize only in
retrospect did not include the
On Wed, Aug 19, 2015 at 3:58 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Add a new flag --signed-if-possible to push and send-pack that sends a
>> push certificate if and only if the server advertised a push cert
>> nonce. If not, at least warn the user that
On Wed, Aug 19, 2015 at 3:56 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Signed-off-by: Dave Borowitz
>> ---
>> Documentation/git-send-pack.txt | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/git-
On Wed, Aug 19, 2015 at 2:00 PM, Stefan Beller wrote:
> On Wed, Aug 19, 2015 at 8:26 AM, Dave Borowitz wrote:
>> The old option parsing code in this plumbing command predates this
>> API, so option parsing was done more manually. Using the new API
>> brings send-pack more i
Signed-off-by: Dave Borowitz
---
Documentation/config.txt | 8
builtin/push.c | 50 ++--
builtin/send-pack.c | 27 +-
3 files changed, 70 insertions(+), 15 deletions(-)
diff --git a/Documentation
Signed-off-by: Dave Borowitz
---
Documentation/git-send-pack.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 6a6..0a0a3fb 100644
--- a/Documentation/git-send-pack.txt
+++ b
have no corresponding field in
git_transport_options; after this change, push_cert is just like
those.
Signed-off-by: Dave Borowitz
---
transport.c | 3 ---
transport.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/transport.c b/transport.c
index 40692f8..3dd6e30 100644
--- a/transport.c
Signed-off-by: Dave Borowitz
---
cache.h | 1 +
config.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index 6bb7119..95d9594 100644
--- a/cache.h
+++ b/cache.h
@@ -1392,6 +1392,7 @@ extern int git_config_with_options(config_fn_t fn, void
The old option parsing code in this plumbing command predates this
API, so option parsing was done more manually. Using the new API
brings send-pack more in line with push, and accepts new variants
like --no-* for negating options.
Signed-off-by: Dave Borowitz
---
builtin/send-pack.c | 163
Signed-off-by: Dave Borowitz
---
Documentation/git-send-pack.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index b5d09f7..6a6 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git
Signed-off-by: Dave Borowitz
---
Documentation/gitremote-helpers.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/gitremote-helpers.txt
b/Documentation/gitremote-helpers.txt
index 82e2d15..78e0b27 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation
Add a new flag --signed-if-possible to push and send-pack that sends a
push certificate if and only if the server advertised a push cert
nonce. If not, at least warn the user that their push may not be as
secure as they thought.
Signed-off-by: Dave Borowitz
---
Documentation/git-push.txt
:
http://thread.gmane.org/gmane.comp.version-control.git/275881
Dave Borowitz (9):
Documentation/git-push.txt: Document when --signed may fail
Documentation/git-send-pack.txt: Flow long synopsis line
Documentation/git-send-pack.txt: Document --signed
gitremote-helpers.txt: Document pushcert
Like --atomic, --signed will fail if the server does not advertise the
necessary capability. In addition, it requires gpg on the client side.
Signed-off-by: Dave Borowitz
---
Documentation/git-push.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/git
On Fri, Aug 14, 2015 at 7:22 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> diff --git a/send-pack.c b/send-pack.c
>> index 2a64fec..6ae9f45 100644
>> --- a/send-pack.c
>> +++ b/send-pack.c
>> @@ -370,7 +370,7 @@ int send_pack(struct send_pa
On Mon, Aug 17, 2015 at 3:54 PM, Junio C Hamano wrote:
> In the shorter term, at least we should be able to introduce
> git_parse_maybe_bool() that does not take "name", use that as a
> helper to implement git_config_maybe_bool(), so that the existing
> callers of git_config_maybe_bool() does not
On Mon, Aug 17, 2015 at 3:42 PM, Junio C Hamano wrote:
>
> Dave Borowitz writes:
>
> > The issue is that if both _ALWAYS and _IF_POSSIBLE are set,
> > git_transport_push interprets it as _ALWAYS. But, we are also supposed
> > to prefer explicit command-li
On Mon, Aug 17, 2015 at 2:47 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> On Mon, Aug 17, 2015 at 1:21 PM, Junio C Hamano wrote:
>>>
>>> My preference on Bikeshed 1. would probably be to add
>>>
>>> --sign=yes/no/if-asked
>>
On Mon, Aug 17, 2015 at 1:21 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Ok, so let us bikeshed a bit further.
>>
>> Bikeshed 1.
>> Option A: --signed/--no-signed--signed-if-possible
>> Option B: --signed=true|false|if-possible, "--signed
On Mon, Aug 17, 2015 at 1:13 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> ---
>
> Does the lack of sign-off indicate something (like "this is just a
> 'what do people think?' weatherbaloon not yet a serious submission")?
>
>> +push.gp
On Fri, Aug 14, 2015 at 7:10 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Like --atomic, --signed will fail if the server does not advertise the
>> necessary capability. In addition, it requires gpg on the client side.
>>
>> Signed-off-by: Dave Borowitz
On Fri, Aug 14, 2015 at 4:45 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> On Fri, Aug 14, 2015 at 2:12 PM, Junio C Hamano wrote:
>>> Yes, it looks somewhat strange.
>> ... The straw-man
>> strangeness is that two of them are the traditional boolean val
On Fri, Aug 14, 2015 at 2:12 PM, Junio C Hamano wrote:
>> The "if-possible" name and weird tri-state boolean is basically a straw man,
>> and I am happy to change if someone has a clearer suggestion.
>
> Yes, it looks somewhat strange. Let me go on a slight tangent to
> explain why I think it is
On Fri, Aug 14, 2015 at 2:12 PM, Junio C Hamano wrote:
> So I am fine as long as "if-possible" turns a failure to make signed
> push into a success _only_ when the reason of the failure is because
> we did not see the capability supported by the receiving end. If
> the reason why you cannot do a
On Sun, Aug 9, 2015 at 12:57 PM, Agostino Sarubbo wrote:
> Hello folks,
>
> during the configuration of git, client side, to sign all commit I used:
>
> git config --global commit.gpgsign "1"
>
>
> Since at push time I use:
>
> git push --signed
>
> I'm wondering if there is a git config option wh
On Tue, Aug 11, 2015 at 3:06 PM, Matthew Thode wrote:
> If it doesn't already exist (not that I can find). I'd like to see
> config options analogous to commit.gpgsign for both tagging and pushing.
I agree this would be useful, and that's why I just implemented it today :)
> Not sure where else
Add a new flag --signed-if-possible to push and send-pack that sends a
push certificate if and only if the server advertised a push cert
nonce. If not, at least warn the user that their push may not be as
secure as they thought.
Signed-off-by: Dave Borowitz
---
Documentation/git-push.txt
---
Documentation/config.txt | 8
builtin/push.c | 22 ++
builtin/send-pack.c | 27 ++-
3 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 016f6e9..6804f5b 100
Signed-off-by: Dave Borowitz
---
Documentation/git-send-pack.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index b5d09f7..6a6 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git
omeone has a clearer suggestion.
Dave Borowitz (7):
Documentation/git-push.txt: Document when --signed may fail
Documentation/git-send-pack.txt: Flow long synopsis line
Documentation/git-send-pack.txt: Document --signed
gitremote-helpers.txt: Document pushcert option
have no corresponding field in
git_transport_options; after this change, push_cert is just like
those.
Signed-off-by: Dave Borowitz
---
transport.c | 3 ---
transport.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/transport.c b/transport.c
index 40692f8..3dd6e30 100644
--- a/transport.c
Signed-off-by: Dave Borowitz
---
Documentation/gitremote-helpers.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/gitremote-helpers.txt
b/Documentation/gitremote-helpers.txt
index 82e2d15..78e0b27 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation
Like --atomic, --signed will fail if the server does not advertise the
necessary capability. In addition, it requires gpg on the client side.
Signed-off-by: Dave Borowitz
---
Documentation/git-push.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/git
Signed-off-by: Dave Borowitz
---
Documentation/git-send-pack.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 6a6..dde13b0 100644
--- a/Documentation/git-send-pack.txt
+++ b
On Thu, Aug 13, 2015 at 12:45 PM, Ilari Liusvaara
wrote:
> On Thu, Aug 13, 2015 at 11:42:50AM -0400, Dave Borowitz wrote:
>>
>> In my ideal world:
>> -smart_options would never be NULL, and would instead be called
>> "options" with a "smart" bit whic
I spent a day trying to understand what the heck is going on in the
transport code, with the intent of adding an option like
--sign-if-possible to git push. This has come up twice on the mailing
list in the past couple weeks, and I also think it's important for
$DAY_JOB.
I'm giving up in despair,
It looks like git config --unset may leave an orphaned section, but a
subsequent set adds a new section:
$ git config --file=myconfig section.foo true
$ git config --file=myconfig --unset section.foo
$ cat myconfig
[section]
$ git config --file=myconfig section.foo true
$ cat myconfig
[section]
[s
Signed-off-by: Dave Borowitz
---
builtin/send-pack.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index b961e5a..23b2962 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -11,6 +11,7 @@
#include "transport.h"
#include &q
On Thu, Jul 16, 2015 at 3:08 PM, Dave Borowitz wrote:
> On Thu, Jul 16, 2015 at 2:10 PM, Junio C Hamano wrote:
>> Dave Borowitz writes:
>>
>>> On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano wrote:
>>>> Dave Borowitz writes:
>>>>
>>>
On Thu, Jul 16, 2015 at 2:10 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano wrote:
>>> Dave Borowitz writes:
>>>
>>>> On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano wrote:
>>>>
>
On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano wrote:
>>
>>> Perhaps something like this?
>>
>> Seems like it should work.
>>
>> Jonathan had suggested the
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> When git-send-pack is exec'ed, as is done by git-remote-http, it does
>> not reread the config, so it does not respect the configured
>> http.signingkey, either from the config file
When git-send-pack is exec'ed, as is done by git-remote-http, it does
not reread the config, so it does not respect the configured
http.signingkey, either from the config file or -c on the command
line. Thus it is currently impossible to specify a signing key over
HTTP, other than the default one m
On Mon, Jul 6, 2015 at 2:06 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano wrote:
>>> Dave Borowitz writes:
>>>
>>>> Another way of looking at the problem with my assumptions is, I was
>>>
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Another way of looking at the problem with my assumptions is, I was
>> assuming "pkt-line framing" was the same thing as "pkt-line header".
>> You seem to be saying the
On Mon, Jul 6, 2015 at 1:30 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> I think I understand the confusion now. I think you and I are working
>> from different assumptions about the client behavior.
>
> I agree that we now both understand where we come from ;
On Mon, Jul 6, 2015 at 1:11 PM, Dave Borowitz wrote:
> On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano wrote:
>> Dave Borowitz writes:
>>
>>> The server can munge pkt-lines and reinsert LFs, but it _must_ have
>>> some way of reconstructing the payload that
On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> The server can munge pkt-lines and reinsert LFs, but it _must_ have
>> some way of reconstructing the payload that the client signed in order
>> to verify the signature. If we just
On Mon, Jul 6, 2015 at 12:28 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> push cert format is like commit or tag format. You need those LFs. We
>> can't just go declare them optional because of the way pkt-line read
>> function is implemented in git-core.
>
> As I said, I view each of th
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz wrote:
> The alternatives for someone writing a parser are:
> a. Store the original pkt-line framing.
Or obviously, a2. Frame in some other way, e.g. JSON array of strings
(complete straw man, not seriously proposing this).
--
To unsubscrib
On Mon, Jul 6, 2015 at 11:27 AM, Dave Borowitz wrote:
> On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz wrote:
>> b. Write a parser in some other clever way, e.g. parsing the entire
>> cert in reverse might work.
>
> ...as long as " " is illegal in nonce and pushe
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz wrote:
> b. Write a parser in some other clever way, e.g. parsing the entire
> cert in reverse might work.
...as long as " " is illegal in nonce and pushee values, which it may
be but is not explicitly documented. I still have no
On Mon, Jul 6, 2015 at 10:46 AM, Dave Borowitz wrote:
> On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano wrote:
>>
>> Dave Borowitz writes:
>>
>> >> I am moderately negative about this; wouldn't it make the end result
>> >> cleaner to fix the i
On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano wrote:
>
> Dave Borowitz writes:
>
> >> I am moderately negative about this; wouldn't it make the end result
> >> cleaner to fix the implementation?
> >
> > I'm not sure I understand your suggestion.
On Wed, Jul 1, 2015 at 1:00 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Signed-off-by: Dave Borowitz
>> ---
>> Documentation/technical/pack-protocol.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/tech
On Wed, Jul 1, 2015 at 12:39 PM, Jonathan Nieder wrote:
> Hi,
>
> Dave Borowitz wrote:
>
>> --- a/Documentation/technical/pack-protocol.txt
>> +++ b/Documentation/technical/pack-protocol.txt
>> @@ -14,6 +14,17 @@ data. The protocol functions to have a se
On Wed, Jul 1, 2015 at 12:07 PM, Junio C Hamano wrote:
> Answering myself, the most trivial example is "git send-pack" ;-)
> It passes args that has a NULL in the .url field.
Well, the example I have involves an actual "git push" command. The
fact that .url is NULL in that case may be a separate
On Wed, Jul 1, 2015 at 11:56 AM, Junio C Hamano wrote:
> Do some clients omit this in the real world?
I just sent you privately a trace where this happens using a recent
git client. With that in the wild, I think our server is going to have
to handle these even if there is a bug and it is fixed p
On Wed, Jul 1, 2015 at 11:21 AM, Stefan Beller wrote:
> I think the problem with this part of the documentation is its ambiguity on
> what exactly we want to document. The sender SHOULD put an LF, while
> the receiver MUST NOT assume the LF is there always, so I guess it's best
> to mark it option
code reduces
confusion for implementors trying to understand the signed push
protocol by looking at the reference implementation.
Signed-off-by: Dave Borowitz
---
send-pack.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/send-pack.c b/send-pack.c
index 2a64fec..77e2131 100644
--- a/send
send-pack.c omits this field when args->url is null or empty. Fix the
protocol specification to match reality.
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/p
We want to fix such inaccuracies, but there are a lot and there is no
guarantee at any particular point in time that this document will be
error-free.
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 66d2d95..1386840 100644
--- a/Documentation/technical/pack
The signed push protocol documentation did not really match the reality of what
send-pack.c and receive-pack.c do, much to my chagrin as I attempted to
implement this protocol in JGit. This series covers most of the issues I found
on a first pass.
Dave Borowitz (7):
pack-protocol.txt: Add
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 1386840..2d8b1a1 100644
--- a/Documentation/technical/pack-protocol.txt
that key).
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 2d8b1a1..de3c72c 100644
--- a
The use of "must" (albeit not in all caps) suggests that this is
actually a requirement of the protocol. As no implementation exists
that actually does this verification, this is misleading at best.
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 3 +
On Tue, Apr 14, 2015 at 4:54 PM, Jeff King wrote:
> On Tue, Apr 14, 2015 at 12:30:23PM -0700, Junio C Hamano wrote:
>
>> > If I recall correctly, Scott said onstage that some/all of the
>> > conference proceeds would be going directly into this fund. So this
>> > might need to be revised upward by
On Mon, Apr 13, 2015 at 7:56 AM, Jeff King wrote:
> # Money: How much do we have?
>
> - $19,059.25 (USD)
>
> // Disclaimer: this is not necessarily up-to-the-minute, as
> // SFC's reports to us sometimes lag a bit. And also because
> // I am fairly inexperienced using the `ledger` program, so
> /
On Wed, Apr 30, 2014 at 8:27 AM, Junio C Hamano wrote:
> How old/battle tested is this change? My inclination at this point
> is to revert the merge of Dave's series from 2.0 (yes, I know we
> have been looking at fixing it and I _think_ the issue of unpleasant
> error message you reported can be
-config is always installed was incorrect.
Instead, if CURL_CONFIG is empty or returns an empty result (e.g. due
to curl-config being missing), use the old behavior of falling back to
-lcurl.
Signed-off-by: Dave Borowitz
---
Makefile | 41 -
1 file changed
On Mon, Apr 28, 2014 at 1:45 PM, Junio C Hamano wrote:
> I still think the implementation of "If CURL_CONFIG is unset" bit is
> a bit redundant, though.
If CURL_CONFIG is unset, then $(shell $(CURL_CONFIG) --libs) produces
"make: --libs: Command not found", which may be confusing.
--
To unsubscri
On Mon, Apr 28, 2014 at 1:05 PM, Jonathan Nieder wrote:
> Dave Borowitz wrote:
>
>> Instead, if CURL_CONFIG is empty or returns an empty result (e.g. due
>> to curl-config being missing), use the old behavior of falling back to
>> -lcurl.
On Mon, Apr 28, 2014 at 1:50 PM, Jonathan Nieder wrote:
>> $ echo -e 'ifndef FOO\n\t$(error bad things)\nendif\n\nfoo:\n\ttouch
>> foo' > mk1 && make -f mk1 foo
>> mk1:2: *** commands commence before first target. Stop.
>> $ echo -e 'ifndef FOO\n $(error bad things)\nendif\n\nfoo:\n\ttouch
>> fo
On Mon, Apr 28, 2014 at 1:46 PM, Dave Borowitz wrote:
> How about:
> "If CURL_CONFIG is unset or points to a binary that is not found,
> defaults to the CURLDIR behavior. If CURLDIR is not set, this means
> using -lcurl with no additional library detection (other than
> NEEDS
On Mon, Apr 28, 2014 at 12:44 PM, Jonathan Nieder wrote:
> Hi,
>
> Dave Borowitz wrote:
>
>> curl-config is usually installed alongside a curl distribution, and
>> its purpose is to provide flags for building against libcurl, so use
>> it instead of guessing flags an
The original implementation of CURL_CONFIG support did not match the
original behavior of using -lcurl when CURLDIR was not set. This broke
implementations that were lacking curl-config but did have libcurl
installed along system libraries, such as MSysGit. In other words, the
assumption that curl-
On Mon, Apr 28, 2014 at 12:40 PM, Junio C Hamano wrote:
> "'Dave Borowitz ' via msysGit"
> writes:
>
>> I think I should probably re-roll the patch to default to the old
>> behavior (blind -lcurl) if curl-config returns the empty string, which
>> I
setting -lcurl.
Signed-off-by: Dave Borowitz
---
Makefile | 51 +--
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index 2128ce3..cb4ee37 100644
--- a/Makefile
+++ b/Makefile
@@ -34,8 +34,14 @@ all::
# git-http
This requires more flags than can be guessed with the old-style
CURLDIR and related options, so is only supported when curl-config is
present.
Signed-off-by: Dave Borowitz
---
Makefile | 12
1 file changed, 12 insertions(+)
diff --git a/Makefile b/Makefile
index cb4ee37..360d427
On Mon, Apr 28, 2014 at 11:31 AM, Junio C Hamano wrote:
> Erik Faye-Lund writes:
>
>> We're using Curl 7.30.0 in msysGit (and thus also Git for Windows), so
>> we should be able to include it. However, we do not have curl-config
>> installed.
>
> Hmmm, between 2.0-rc0 and 2.0-rc1 there is 61a64ff
This requires more flags than can be guessed with the old-style
CURLDIR and related options, so is only supported when curl-config is
present.
Signed-off-by: Dave Borowitz
---
Makefile | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
/dborowitz/d/curl-out-7.36.0/lib -lcurl -lgssapi_krb5 -lresolv -lldap
-lz
Use this only when CURLDIR is not explicitly specified, to continue
supporting older builds.
Signed-off-by: Dave Borowitz
---
Makefile | 35 +++
1 file changed, 23 insertions(+), 12
On Mon, Apr 14, 2014 at 4:22 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> curl-config should always be installed alongside a curl distribution,
>> and its purpose is to provide flags for building against libcurl, so
>> use it instead of guessing flags
Signed-off-by: Dave Borowitz
---
Makefile | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index d6330bc..3c151d3 100644
--- a/Makefile
+++ b/Makefile
@@ -37,6 +37,9 @@ all::
# Define CURL_CONFIG to the path to a curl-config binary other than the
other than the first in PATH.
Use this only when CURLDIR is not explicitly specified, to continue
supporting older builds.
Signed-off-by: Dave Borowitz
---
Makefile | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
On Mon, Aug 5, 2013 at 8:59 AM, Brian Gernhardt
wrote:
>
> The URL included in the header appears to vary from curl version to
> curl version. Since we only care about the final few lines, only test
> them. However, make sure the blank line after the header is still
> included to make sure there
On Wed, Sep 19, 2012 at 10:59 AM, Junio C Hamano wrote:
> dborow...@google.com writes:
>
>> From: Dave Borowitz
>>
>> Signed-off-by: Dave Borowitz
>> ---
>
> Thanks; the patch sort-of makes sense but makes me wonder what your
> use case is. Do you have
On Fri, Aug 10, 2012 at 11:08 AM, Jeff King wrote:
> On Fri, Aug 10, 2012 at 11:06:08AM -0700, Dave Borowitz wrote:
>
>> > I asked the folks who run code.google.com and they are indeed seeing
>> > something like these in their logs:
>> >
>> > >&
On Fri, Aug 10, 2012 at 8:37 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> Ugh, the jk/version-string topic breaks fetching from Google Code. With
>> my patch, the client unconditionally sends an "agent=foo" capability,
>> but the server does not like seeing the unknown capability and ends t
99 matches
Mail list logo
