Re: [PATCH v2] completion: reduce overhead of clearing cached --options

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

[PATCH] config.txt: Document behavior of backslashes in subsections

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 ---

Re: reftable [v4]: new ref storage format

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

Re: reftable [v4]: new ref storage format

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

Re: reftable [v4]: new ref storage format

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

Re: reftable: new ref storage format

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

Re: reftable: new ref storage format

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

Re: RefTree: Alternate ref backend

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

Re: Building Git with HTTPS support: avoiding libcurl?

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

Re: [PATCH 0/2] git-candidate: git based patch tracking and review

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

[PATCH v2 7/9] builtin/send-pack.c: Use option parsing API

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

[PATCH v2 5/9] transport: Remove git_transport_options.push_cert

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

[PATCH v2 6/9] config.c: Expose git_parse_maybe_bool

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

[PATCH v2 3/9] Documentation/git-send-pack.txt: Document --signed

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

[PATCH v2 9/9] Add a config option push.gpgSign for default signed pushes

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

Re: [PATCH 6/7] Support signing pushes iff the server supports it

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

[PATCH v2 8/9] Support signing pushes iff the server supports it

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

[PATCH v2 4/9] gitremote-helpers.txt: Document pushcert option

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

[PATCH v2 1/9] Documentation/git-push.txt: Document when --signed may fail

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

[PATCH v2 2/9] Documentation/git-send-pack.txt: Flow long synopsis line

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

[PATCH v2 0/9] Flags and config to sign pushes by default

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

Re: [PATCH v2 7/9] builtin/send-pack.c: Use option parsing API

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

Re: [PATCH v2 2/9] Documentation/git-send-pack.txt: Flow long synopsis line

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

Re: [PATCH v2 8/9] Support signing pushes iff the server supports it

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

Re: [PATCH 1/7] Documentation/git-push.txt: Document when --signed may fail

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

Re: [PATCH 7/7] Add a config option push.gpgSign for default signed pushes

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

Re: [PATCH 0/7] Flags and config to sign pushes by default

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

Re: [PATCH 0/7] Flags and config to sign pushes by default

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

Re: [PATCH 0/7] Flags and config to sign pushes by default

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

Re: [PATCH 7/7] Add a config option push.gpgSign for default signed pushes

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

Re: [PATCH 0/7] Flags and config to sign pushes by default

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

Re: [PATCH 0/7] Flags and config to sign pushes by default

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

Re: [PATCH 0/7] Flags and config to sign pushes by default

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

Re: Thoughts on refactoring the transport (+helper) code

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

[PATCH 5/7] transport: Remove git_transport_options.push_cert

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

[PATCH 7/7] Add a config option push.gpgSign for default signed pushes

--- 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

[PATCH 2/7] Documentation/git-send-pack.txt: Flow long synopsis line

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

[PATCH 0/7] Flags and config to sign pushes by default

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

[PATCH 6/7] Support signing pushes iff the server supports it

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

[PATCH 3/7] Documentation/git-send-pack.txt: Document --signed

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

[PATCH 1/7] Documentation/git-push.txt: Document when --signed may fail

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

[PATCH 4/7] gitremote-helpers.txt: Document pushcert option

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

Re: An option to sign the push by default

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

Re: config options for automatic signed tags and signed pushes

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

Thoughts on refactoring the transport (+helper) code

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,

Bug? git config and --unset are not inverses

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]

Re: Bug: send-pack does not respect http.signingkey

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

[PATCH] builtin/send-pack.c: Respect http.signingkey

...`. 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

Bug: send-pack does not respect http.signingkey

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

Re: Bug: send-pack does not respect http.signingkey

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

Re: Bug: send-pack does not respect http.signingkey

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

Re: Bug: send-pack does not respect http.signingkey

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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.

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

[PATCH 5/7] pack-protocol.txt: Be more precise about pusher-key relationship

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

[PATCH 6/7] pack-protocol.txt: Mark pushee field as optional

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

[PATCH 1/7] pack-protocol.txt: Add warning about protocol inaccuracies

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

[PATCH 2/7] pack-protocol.txt: Mark LF in command-list as optional

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

[PATCH 0/7] Clarify signed push protocol documentation

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

Re: [PATCH 2/7] pack-protocol.txt: Mark LF in command-list as optional

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

[PATCH 7/7] send-pack.c: Die if the nonce is empty

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

Re: [PATCH 1/7] pack-protocol.txt: Add warning about protocol inaccuracies

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

Re: [PATCH 6/7] pack-protocol.txt: Mark pushee field as optional

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

Re: [PATCH 6/7] pack-protocol.txt: Mark pushee field as optional

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

Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

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

Re: Git + SFC Status Update

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

Re: Git + SFC Status Update

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,

Re: [PATCH/RFC] Makefile: do not depend on curl-config

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

Re: git version 1.9.0 missing git-http-push?

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

[PATCH v3 2/2] Makefile: allow static linking against libcurl

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

Re: git version 1.9.0 missing git-http-push?

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

[PATCH] Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

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

Re: [PATCH v3 1/2] Makefile: use curl-config to determine curl flags

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

Re: [PATCH] Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

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_

Re: [PATCH] Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

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

Re: [PATCH] Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

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

Re: [PATCH] Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

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. --

[PATCH v2] Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

-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

Re: [PATCH 1/2] Makefile: use curl-config to determine curl flags

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

[PATCH v2 2/2] Makefile: allow static linking against libcurl

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

[PATCH v2 1/2] Makefile: use curl-config to determine curl flags

/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

[PATCH 2/2] Makefile: allow static linking against libcurl

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

[PATCH 1/2] Makefile: use curl-config to determine curl flags

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

Re: [PATCH 0/4] jk/version-string and google code

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