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
---
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
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
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
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
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
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
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
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
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 dborow...@google.com
---
builtin
that have no corresponding field in
git_transport_options; after this change, push_cert is just like
those.
Signed-off-by: Dave Borowitz dborow...@google.com
---
transport.c | 3 ---
transport.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/transport.c b/transport.c
index 40692f8..3dd6e30
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/config.txt | 8
builtin/push.c | 50 ++--
builtin/send-pack.c | 27 +-
3 files changed, 70 insertions(+), 15 deletions(-)
diff --git
On Fri, Aug 14, 2015 at 7:22 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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_pack_args *args
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 dborow...@google.com
---
Documentation
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
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 dborow...@google.com
---
Documentation/git-push.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
at:
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
On Wed, Aug 19, 2015 at 2:00 PM, Stefan Beller sbel...@google.com wrote:
On Wed, Aug 19, 2015 at 8:26 AM, Dave Borowitz dborow...@google.com 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
On Wed, Aug 19, 2015 at 3:56 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/git-send-pack.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git
On Wed, Aug 19, 2015 at 3:58 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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
On Fri, Aug 14, 2015 at 7:10 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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 Mon, Aug 17, 2015 at 1:13 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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.gpgSign::
+ May be set
On Mon, Aug 17, 2015 at 1:21 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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 alone implies =true
On Mon, Aug 17, 2015 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Mon, Aug 17, 2015 at 1:21 PM, Junio C Hamano gits...@pobox.com wrote:
My preference on Bikeshed 1. would probably be to add
--sign=yes/no/if-asked
and to keep
On Mon, Aug 17, 2015 at 3:54 PM, Junio C Hamano gits...@pobox.com 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
On Mon, Aug 17, 2015 at 3:42 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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-line options
On Fri, Aug 14, 2015 at 2:12 PM, Junio C Hamano gits...@pobox.com 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
On Fri, Aug 14, 2015 at 2:12 PM, Junio C Hamano gits...@pobox.com 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
On Fri, Aug 14, 2015 at 4:45 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Fri, Aug 14, 2015 at 2:12 PM, Junio C Hamano gits...@pobox.com wrote:
Yes, it looks somewhat strange.
... The straw-man
strangeness is that two of them are the traditional
On Thu, Aug 13, 2015 at 12:45 PM, Ilari Liusvaara
ilari.liusva...@elisanet.fi 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 which is unset for dumb protocols
that have no corresponding field in
git_transport_options; after this change, push_cert is just like
those.
Signed-off-by: Dave Borowitz dborow...@google.com
---
transport.c | 3 ---
transport.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/transport.c b/transport.c
index 40692f8..3dd6e30
---
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
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
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
transport: Remove
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 dborow...@google.com
---
Documentation
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
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 dborow...@google.com
---
Documentation/git-push.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
On Sun, Aug 9, 2015 at 12:57 PM, Agostino Sarubbo a...@gentoo.org 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
On Tue, Aug 11, 2015 at 3:06 PM, Matthew Thode mth...@mthode.org 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
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]
On Thu, Jul 16, 2015 at 3:08 PM, Dave Borowitz dborow...@google.com wrote:
On Thu, Jul 16, 2015 at 2:10 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow
...`.
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
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
On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano gits...@pobox.com wrote:
Perhaps something like this?
Seems like it should work.
Jonathan had suggested there might be some
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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
On Thu, Jul 16, 2015 at 2:10 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano gits
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz dborow...@google.com 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
On Mon, Jul 6, 2015 at 2:06 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Another way of looking at the problem with my assumptions
On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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 1:30 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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
On Mon, Jul 6, 2015 at 1:11 PM, Dave Borowitz dborow...@google.com wrote:
On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
The server can munge pkt-lines and reinsert LFs, but it _must_ have
some way of reconstructing
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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 definition of pkt
On Mon, Jul 6, 2015 at 12:28 PM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org 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.
On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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. Are you saying, you would
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz dborow...@google.com 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
On Mon, Jul 6, 2015 at 11:27 AM, Dave Borowitz dborow...@google.com wrote:
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz dborow...@google.com 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
On Mon, Jul 6, 2015 at 10:46 AM, Dave Borowitz dborow...@google.com wrote:
On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
I am moderately negative about this; wouldn't it make the end result
cleaner to fix
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 dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 3
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 dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation
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 dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 11 +++
1 file changed, 11 insertions
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
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
On Wed, Jul 1, 2015 at 11:21 AM, Stefan Beller sbel...@google.com 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
in the code reduces
confusion for implementors trying to understand the signed push
protocol by looking at the reference implementation.
Signed-off-by: Dave Borowitz dborow...@google.com
---
send-pack.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/send-pack.c b/send-pack.c
index 2a64fec
On Wed, Jul 1, 2015 at 12:39 PM, Jonathan Nieder jrnie...@gmail.com 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 server tell a
client what
On Wed, Jul 1, 2015 at 12:07 PM, Junio C Hamano gits...@pobox.com 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
On Wed, Jul 1, 2015 at 11:56 AM, Junio C Hamano gits...@pobox.com 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
On Wed, Jul 1, 2015 at 1:00 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
Signed-off-by: Dave Borowitz dborow...@google.com
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/technical
On Tue, Apr 14, 2015 at 4:54 PM, Jeff King p...@peff.net 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
On Mon, Apr 13, 2015 at 7:56 AM, Jeff King p...@peff.net 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,
On Wed, Apr 30, 2014 at 8:27 AM, Junio C Hamano gits...@pobox.com 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
On Mon, Apr 28, 2014 at 11:31 AM, Junio C Hamano gits...@pobox.com wrote:
Erik Faye-Lund kusmab...@gmail.com 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
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 dborow...@google.com
---
Makefile | 12
1 file changed, 12 insertions(+)
diff --git a/Makefile b/Makefile
On Mon, Apr 28, 2014 at 12:40 PM, Junio C Hamano gits...@pobox.com wrote:
'Dave Borowitz dborow...@google.com' via msysGit
msys...@googlegroups.com 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
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
On Mon, Apr 28, 2014 at 12:44 PM, Jonathan Nieder jrnie...@gmail.com 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 and dependent libraries
On Mon, Apr 28, 2014 at 1:46 PM, Dave Borowitz dborow...@google.com 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 1:50 PM, Jonathan Nieder jrnie...@gmail.com 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
On Mon, Apr 28, 2014 at 1:05 PM, Jonathan Nieder jrnie...@gmail.com 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.
---
Makefile | 36
On Mon, Apr 28, 2014 at 1:45 PM, Junio C Hamano gits...@pobox.com 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.
--
-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 dborow...@google.com
---
Makefile | 41
On Mon, Apr 14, 2014 at 4:22 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com 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
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 dborow...@google.com
---
Makefile | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git
/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 dborow...@google.com
---
Makefile | 35 +++
1 file changed, 23
Signed-off-by: Dave Borowitz dborow...@google.com
---
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
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 dborow...@google.com
---
Makefile | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git
On Fri, Aug 10, 2012 at 8:37 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net 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
93 matches
Mail list logo