git@vger.kernel.org

small detail from there would be useful to have in the commit message: namely that this was detected using --chain-lint (and what command I can run to reproduce it myself). With or without such a tweak to the commit message, Reviewed-by: Jonathan Nieder Thanks. > contrib/mw-to-git/t/t9360-mw-to

Re: [PATCH v2 01/10] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells

Eric Sunshine wrote: > On Mon, Jul 30, 2018 at 2:14 PM Jonathan Nieder wrote: >> ( >> chks_sub=$(cat <> $chks >> TXT >> ) && >> >> Ugly quoting, useless use of "cat", etc, aside, I don't think it&

[PATCH 2/2] subtree test: simplify preparation of expected results

that its subshells use an unbroken &&-chain, causing "make -C contrib/subtree test" to fail with error: bug in the test script: broken &&-chain or run-away HERE-DOC: in t7900.21. Signed-off-by: Jonathan Nieder --- That's the end of the series. Thanks

git@vger.kernel.org

Detected using t/chainlint. Signed-off-by: Jonathan Nieder --- contrib/subtree/t/t7900-subtree.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh index d05c613c97..e6a28f2c3e 100755 --- a/contrib

[PATCH 0/2] subtree: fix &&-chain and simplify tests (Re: [PATCH v2 01/10] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells)

(resetting cc list) Jonathan Nieder wrote: > This is causing contrib/subtree tests to fail for me: running "make -C > contrib/subtree test" produces [...] > error: bug in the test script: broken &&-chain or run-away HERE-DOC: [...] > Ugly quoting, useless use

Re: [PATCH v2 01/10] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells

Hi, Eric Sunshine wrote: > The --chain-lint option detects broken &&-chains by forcing the test to > exit early (as the very first step) with a sentinel value. If that > sentinel is the test's overall exit code, then the &&-chain is intact; > if not, then the chain is broken. Unfortunately, this

Re: Proposed approaches to supporting HTTP remotes in "git archive"

(just cc-ing René Scharfe, archive expert; Peff; Dscho; Franck Bui-Huu to see how his creation is evolving. Using the correct address for René this time. Sorry for the noise.) Josh Steadmon wrote: > # Supporting HTTP remotes in "git archive" > > We would like to allow remote archiving from HTTP

Re: Proposed approaches to supporting HTTP remotes in "git archive"

(just cc-ing René Scharfe, archive expert; Peff; Dscho; Franck Bui-Huu to see how his creation is evolving) Josh Steadmon wrote: > # Supporting HTTP remotes in "git archive" > > We would like to allow remote archiving from HTTP servers. There are a > few possible implementations to be discussed: >

Re: [PATCH v2] packfile: ensure that enum object_type is defined

and include cache.h > instead to make sure the enum is defined. > > Helped-by: Jonathan Nieder > Signed-off-by: Beat Bolli > --- > packfile.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks! I had run into this using clang on Linux, too, but hadn'

Re: [PATCH 2/2] doc hash-function-transition: pick SHA-256 as NewHash

Hi, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: >> The consensus on the mailing list seems to be that SHA-256 should be >> picked as our NewHash, see the "Hash algorithm analysis" thread as of >> [1]. Linus has come around to this choice and suggested Junio make the >> final pick, a

Re: [PATCH] pack-protocol: mention and point to docs for protocol v2

Brandon Williams wrote: > If so I suggest we move away from the term "pack" protocol. Mostly > because maybe at some future date we don't only want to communicate to > transfer packs. So at the risk of bikeshedding (and because naming is > hard) I think we should begin talking about the over the

Re: [PATCH] diff: --color-moved: rename "dimmed_zebra" to "dimmed-zebra"

en people see dimmed_zebra in scripts or configuration they won't have to be mystified about why it works. I don't have any good ideas about deprecating more aggressively, and the patch looks good, so Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH 2/2] remote-odb: un-inline function remote_odb_reinit

Hi, Beat Bolli wrote: > When compiling under Apple LLVM version 9.1.0 (clang-902.0.39.2) with > "make DEVELOPER=1 DEVOPTS=pedantic", the compiler says > > remote-odb.c:87:2: error: static function 'remote_odb_do_init' is > used in an inline function with external linkage > [-Werror,-W

Re: [PATCH 1/2] packfile: drop a repeated enum declaration

Hi, Beat Bolli wrote: > --- a/packfile.h > +++ b/packfile.h > @@ -6,7 +6,6 @@ > /* in object-store.h */ > struct packed_git; > struct object_info; > -enum object_type; > > /* > * Generate the filename to be used for a pack file with checksum "sha1" and Good catch. This means packfile.h

Re: de-alphabetizing the documentation

Hi, frede...@ofb.net wrote: > Next week I should have time to send you a patch with the manual page > reordered... Yay! > although, unless you have a special 'diff' which can > detect when text has been moved from one place to another, I'm > guessing it would take you even longer

Re: Hash algorithm analysis

Hi, Linus Torvalds wrote: > On Tue, Jul 24, 2018 at 12:01 PM Edward Thomson > wrote: >> Switching gears, if I look at this from the perspective of the libgit2 >> project, I would also prefer SHA-256 or SHA3 over blake2b. To support >> blake2b, we'd have to include - and support - that code ours

Re: [PATCH] pack-protocol: mention and point to docs for protocol v2

Hi, Brandon Williams wrote: > --- a/Documentation/technical/pack-protocol.txt > +++ b/Documentation/technical/pack-protocol.txt > @@ -50,7 +50,8 @@ Each Extra Parameter takes the form of `=` or > ``. > > Servers that receive any such Extra Parameters MUST ignore all > unrecognized keys. Curr

Re: [PATCH] Documentation/diff-options: explain different diff algorithms

Hi, Stefan Beller wrote: > As a user I wondered what the diff algorithms are about. Offer at least > a basic explanation on the differences of the diff algorithms. Interesting. Let's see. [...] > --- a/Documentation/diff-options.txt > +++ b/Documentation/diff-options.txt > @@ -94,16 +94,34 @@

Re: [PATCH] fetch-pack: mark die strings for translation

Brandon Williams wrote: > Signed-off-by: Brandon Williams > --- > fetch-pack.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH v6 8/8] fetch-pack: implement ref-in-want

Hi, Duy Nguyen wrote: > On Mon, Jul 23, 2018 at 7:53 PM Brandon Williams wrote: >> What criteria is used to determine if something should be translated? [...] > Besides drawing the line "benefit from (not) being translated" varies > from one developer to another. I think it's just easier and mor

Re: Hash algorithm analysis

Hi Yves, demerphq wrote: > On Sun, 22 Jul 2018 at 01:59, brian m. carlson > wrote: >> I will admit that I don't love making this decision by myself, because >> right now, whatever I pick, somebody is going to be unhappy. [...] > I do not envy you this decision. > > Personally I would aim towards

Re: [PATCH 2/9] vscode: hard-code a couple defines

Hi, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > Sadly, we do not get all of the definitions via ALL_CFLAGS. Some defines > are passed to GCC *only* when compiling specific files, such as git.o. > > Let's just hard-code them into the script for the time being. Cou

Re: [PATCH 1/9] contrib: add a script to initialize VS Code configuration

Hi, Thanks for working on this. Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > VS Code is a lightweight but powerful source code editor which runs on > your desktop and is available for Windows, macOS and Linux. Among other > languages, it has support for C/C++ via

Re: Hash algorithm analysis

Hi, brian m. carlson wrote: > I know this discussion has sort of petered out, but I'd like to see if > we can revive it. I'm writing index v3 and having a decision would help > me write tests for it. Nice! That's awesome. > To summarize the discussion that's been had in addition to the above,

Re: [PATCH] clone: send ref-prefixes when using protocol v2

Hi, Brandon Williams wrote: > Signed-off-by: Brandon Williams > --- > Noticed we miss out on server side filtering of refs when cloning using > protocol v2, this will enable that. > > builtin/clone.c | 22 +- > 1 file changed, 17 insertions(+), 5 deletions(-) Nice! The imp

Re: [PATCH] gc: do not warn about too many loose objects

Hi Ævar, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jul 17 2018, Jonathan Nieder wrote: >> That suggests a possible improvement. If all callers should be >> ignoring the exit code, can we make the exit code in daemonize mode >> unconditionally zero in this kind of case?

[PATCH 3/3] gc: do not return error for prior errors in daemonized mode

it of the same behavior as tools like "git fetch" that ignore the exit status from gc --auto. Once the period of time described by gc.pruneExpire elapses, the unreachable loose objects will be removed by "git gc --auto" automatically. [1] https://gerrit-review.googlesource.com

[PATCH 2/3] gc: exit with status 128 on failure

A value of -1 returned from cmd_gc gets propagated to exit(), resulting in an exit status of 255. Use die instead for a clearer error message and a controlled exit. Signed-off-by: Jonathan Nieder --- As in https://public-inbox.org/git/20180716225639.gk11...@aiede.svl.corp.google.com/. The only

[PATCH 1/3] gc: improve handling of errors reading gc.log

#x27;read', too - avoid being confused by a gc.log larger than INT_MAX bytes Noticed by code inspection. Signed-off-by: Jonathan Nieder --- Split out from https://public-inbox.org/git/20180716225639.gk11...@aiede.svl.corp.google.com/. builtin/gc.c | 9 ++--- 1 file changed, 6 insert

[PATCH v2 0/3] gc --auto: do not return error for prior errors in daemonized mode

wrote this warning to the log > file, and returned 0; but a subsequent run merely read the log file, saw > that it is non-empty and returned -1 (which is inconsistent in that such > a run should return 0, as it did the first time). Here's a series to address that motivating case.

Re: [PATCH] gc: do not warn about too many loose objects

Hi, Jeff King wrote: > On Mon, Jul 16, 2018 at 03:56:39PM -0700, Jonathan Nieder wrote: >> The calling command in the motivating example is Android's "repo" tool: >> >> bare_git.gc('--auto') >> >> from https://gerrit-rev

Re: [PATCH] gc: do not warn about too many loose objects

Jeff King wrote: > On Mon, Jul 16, 2018 at 03:03:06PM -0700, Jonathan Nieder wrote: >> Oh, good point. In non-daemon mode, we don't let "gc --auto" failure >> cause the invoking command to fail, but in daemon mode we do. That >> should be a straightforward f

Re: [PATCH] gc: do not warn about too many loose objects

lure cause the invoking command to fail, but in daemon mode we do. That should be a straightforward fix; patch coming in a moment. > On Mon, Jul 16, 2018 at 02:40:03PM -0700, Jonathan Nieder wrote: >> For comparison, in non-daemon mode, there is nothing enforcing the >> kind of rat

Re: [PATCH] gc: do not warn about too many loose objects

Jeff King wrote: > On Mon, Jul 16, 2018 at 01:37:53PM -0700, Jonathan Nieder wrote: >> Jeff King wrote: >>> With the current code, that produces a bunch of annoying warnings for >>> every commit ("I couldn't gc because the last gc reported a warning"). &g

Re: [PATCH] gc: do not warn about too many loose objects

Elijah Newren wrote: > I totally agree with your general plan to put unreferenced loose > objects into a pack. However, I don't think these objects should be > part of that pack; they should just be deleted instead. This might be the wrong thread to discuss it, but did you follow the reference/p

Re: [PATCH] gc: do not warn about too many loose objects

Jeff King wrote: > On Mon, Jul 16, 2018 at 01:21:40PM -0700, Elijah Newren wrote: >> Jonathan Nieder wrote: >>> My understanding is that exploding the objects is intentional behavior, >>> to avoid a race where objects are newly referenced while they are being >>&

Re: [PATCH] gc: do not warn about too many loose objects

Jeff King wrote: > On Mon, Jul 16, 2018 at 12:54:31PM -0700, Jonathan Nieder wrote: >> Even restricting attention to the warning, not the exit code, I think >> you are saying the current behavior is acceptable. I do not believe >> it is. > > I didn't say that at

Re: [PATCH] gc: do not warn about too many loose objects

Jeff King wrote: > On Mon, Jul 16, 2018 at 12:09:49PM -0700, Jonathan Nieder wrote: >> Jeff King wrote: >>> Er, the action is to run "git prune", like the warning says. :) >> >> I don't think we want to recommend that, especially when "git gc --au

Re: [PATCH] gc: do not warn about too many loose objects

Hi, Elijah Newren wrote: > The basic problem here, at least for us, is that gc has enough > information to know it could expunge some objects, but because of how > it is structured in terms of several substeps (reflog expiration, > repack, prune), the information is lost between the steps and it

Re: [PATCH] gc: do not warn about too many loose objects

Hi, Jeff King wrote: > On Mon, Jul 16, 2018 at 11:22:07AM -0700, Jonathan Nieder wrote: >> Jeff King wrote: >>> So while I completely agree that it's not a great thing to encourage >>> users to blindly run "git prune", I think it _is_ actionable. >&g

Re: [PATCH] gc: do not warn about too many loose objects

Hi, Jeff King wrote: > On Mon, Jul 16, 2018 at 10:27:17AM -0700, Jonathan Tan wrote: >> In a087cc9819 ("git-gc --auto: protect ourselves from accumulated >> cruft", 2007-09-17), the user was warned if there were too many >> unreachable loose objects. This made sense at the time, because gc >> cou

Git standup on IRC

Hi, Some of us have been informally doing a "git standup" on #git-devel on irc.freenode.net on IRC every two weeks at 17:00-17:30 UTC. It's a way for people to say what they're working on and ask questions. It generally goes into a lot less depth than on-list discussions like https://public-inbo

Re: Git 2.18: RUNTIME_PREFIX... is it working?

A quick correction: Jonathan Nieder wrote: > Similarly, various features of other tools (like bash's > support for <(echo hi)) also rely on /proc. That relies on /dev/fd, not /proc, but same idea. Tools like "ps" rely on /proc. Sorry for the noise, Jonathan

Re: Git 2.18: RUNTIME_PREFIX... is it working?

Hi, Jeff King wrote: > My point is that aside from RUNTIME_PREFIX, we don't need /proc. So > somebody who currently builds Git with a static path like > "/usr/libexec/git-core" and runs it inside a chroot will be just fine as > long as /usr/libexec/git-core is available at that name inside the >

Re: I can do past and feature commits. It is a bug?

+the public git mailing list, git-secur...@googlegroups.com -> bcc Hi, Lin Terry wrote: > I can do past and feature commits. It is a bug? > > Check out my gitgub page. > https://github.com/terrylinooo > > You can see a LOVE, they are past commits I commited yesterday. The ability to set the auth

Re: Subscribing Apple people to git-secur...@googlegroups.com

+git@vger Jeff King wrote: > On Tue, Jul 03, 2018 at 08:48:14AM -0700, Jonathan Nieder wrote: >> Administrivia: do you mind if I bounce these messages to some archived >> list, either git@vger.kernel.org or git-security? Or if we'd prefer >> to avoid the noise from t

Re: Subscribing Apple people to git-secur...@googlegroups.com

Administrivia: do you mind if I bounce these messages to some archived list, either git@vger.kernel.org or git-security? Or if we'd prefer to avoid the noise from that, do you mind if I work with Eric Wong to get them injected in the https://public-inbox.org/ archive? Hi, Jeff King wrote: > On M

Re: [PATCH v2 2/2] fetch: send "refs/tags/" prefix upon CLI refspecs

Hi, Jonathan Tan wrote: > --- a/builtin/fetch.c > +++ b/builtin/fetch.c > @@ -359,7 +359,7 @@ static struct ref *get_ref_map(struct transport > *transport, > refspec_ref_prefixes(&transport->remote->fetch, &ref_prefixes); > > if (ref_prefixes.argc && > - (tags == TA

Re: de-alphabetizing the documentation

day(7) but the more interactive first command might be useful for some people. Thoughts? Improvements? -- >8 -- Subject: git doc: recommend "git help" as a starting point The list of subcommands described in git(1) can be overwhelming. Encourage newcomers to run "git help"

Re: [PATCH 0/2] Avoiding errors when partial cloning a tagged blob

Hi, Junio C Hamano wrote: >> Jonathan Tan writes: >>> When cloning a repository with a tagged blob (like the Git repository) >>> with --filter=blob:none, the following message appears: >>> >>> error: missing object referenced by 'refs/tags/junio-gpg-pub' >>> >>> and the resulting reposit

Re: de-alphabetizing the documentation

Jonathan Nieder wrote: > Ideas? If you start with a proposal, we're happy to help refine it. > People in the #git channel on irc.freenode.net (wechat.freenode.net) > might also be useful for inspiration in coming up with a proposal. I meant to link to webchat.freenode.n

Re: de-alphabetizing the documentation

Hi Frederick, Frederick Eaton wrote: > I am trying to learn how to use Git but I've been put off by not > knowing where to start. I would like to start with the 'git' man page, > but it lists the Git subcommands in alphabetical order, rather than in > an order which would be useful for learners.

Re: [PATCH 00/29] t: detect and fix broken &&-chains in subshells

Jun 26, 2018 at 03:31:11PM -0700, Junio C Hamano wrote: > Eric Sunshine writes: >> On Tue, Jun 26, 2018 at 3:38 PM Junio C Hamano wrote: >>> I like these earlier changes that fix existing breakage, of course. >>> I also like many of the changes that simplify and/or modernise the >>> test scripts

Re: [PATCH] fetch-pack: support negotiation tip whitelist

Hi, Jonathan Tan wrote: > During negotiation, fetch-pack eventually reports as "have" lines all > commits reachable from all refs. Allow the user to restrict the commits > sent in this way by providing a whitelist of tips; only the tips > themselves and their ancestors will be sent. > > This feat

Re: [PATCH v3 8/8] fetch-pack: implement ref-in-want

Hi, Brandon Williams wrote: > Implement ref-in-want on the client side so that when a server supports > the "ref-in-want" feature, a client will send "want-ref" lines for each > reference the client wants to fetch. > > Signed-off-by: Brandon Williams > --- > fetch-pack.c |

Re: [PATCH v2 8/8] fetch-pack: implement ref-in-want

Hi, Brandon Williams wrote: > On 06/14, Stefan Beller wrote: > > On Wed, Jun 13, 2018 at 2:39 PM Brandon Williams wrote: >>> + for (r = refs; r; r = r->next) { >>> + if (!strcmp(end, r->name)) { >>> + oidcpy(&r->old_oid, &oid); >>

Re: [PATCH v3 5/8] fetch: refactor fetch_refs into two functions

Brandon Williams wrote: > --- a/builtin/fetch.c > +++ b/builtin/fetch.c > @@ -967,10 +967,16 @@ static int fetch_refs(struct transport *transport, > struct ref *ref_map) > int ret = quickfetch(ref_map); > if (ret) > ret = transport_fetch_refs(transport, ref_map); > -

Re: [PATCH v3 5/8] fetch: refactor fetch_refs into two functions

Hi, Brandon Williams wrote: > [Subject: fetch: refactor fetch_refs into two functions] > > Refactor the fetch_refs function into a function that does the fetching > of refs and another function that stores them. > > Signed-off-by: Brandon Williams > --- > builtin/fetch.c | 19 +-

Re: [PATCH v3 1/8] test-pkt-line: add unpack-sideband subcommand

t; + band = reader.line[0] & 0xff; reader.line[0] is a char. This promotes it to an 'int' and then ANDs against 0xff, which would ensure it is a positive value. In other words, this does the same thing as band = (int) (unsigned char) reader.line[0]; but more concisely. More importantly, it matches what recv_sideband does. Good. Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH] protocol-v2 doc: put HTTP headers after request

Jonathan Nieder wrote: > Josh Steadmon wrote: >> HTTP servers return 400 if you send headers before the GET request. [...] > Tested using > > openssl s_client -connect github.com:443 > > with input > > GET /git/git/info/refs?service=git-upload-pack HTTP/1.

Re: [PATCH] protocol-v2 doc: put HTTP headers after request

;-) Tested using openssl s_client -connect github.com:443 with input GET /git/git/info/refs?service=git-upload-pack HTTP/1.0 Host: github.com Git-Protocol: version=2 which produces a 404 instead of the 400 that putting Git-Protocol in front would produce. Reviewed-by: Jonathan Nieder

Re: want option to git-rebase

Johannes Sixt wrote: > Am 19.06.2018 um 03:06 schrieb Jonathan Nieder: >> Ian Jackson wrote[1]: >>> git-rebase leaves entries like this in the reflog: >>> >>>c15f4d5391 HEAD@{33}: rebase: checkout >>> c15f4d5391ff07a718431aca68a73e672fe8870e >

Re: want option to git-rebase

Hi, Ian Jackson wrote[1]: > git-rebase leaves entries like this in the reflog: > > c15f4d5391 HEAD@{33}: rebase: checkout > c15f4d5391ff07a718431aca68a73e672fe8870e > > It would be nice if there were an option to control this message. > Particularly, when another tool invokes git-rebase, the o

Re: [ANNOUNCE] Git v2.16.0-rc0

Hi, Jeff King wrote: > On Thu, Jun 14, 2018 at 11:55:22AM -0700, Jonathan Nieder wrote: >> Do you mean that it doesn't pass "-G" through, or that when using old >> versions of openssh that doesn't support "-G" the probing fails? > > It just do

Re: [ANNOUNCE] Git v2.16.0-rc0

Hi, Sorry for the slow replies. I was out of office earlier and am back now. Jeff King wrote: > On Tue, Jun 12, 2018 at 09:29:13AM -0700, Junio C Hamano wrote: >> Jeff King writes: >>> To be honest, I could easily see an argument that I _should_ be setting >>> GIT_SSH_VARIANT to explain what m

Re: [PATCH] builtin/send-pack: populate the default configs

ect ids (good). - core.compression, core.packedgitwindowsize, etc: pack generation tunables (good). - advice.*: would allow us to make "git push" produce configurable advice (good!) - etc So it looks like a very good change. Thanks for writing it. Reviewed-by: Jonathan Nieder

Re: [PATCH] builtin/send-pack: report gpg config errors

Hi, Stefan Beller wrote: > Any caller except of git_gpg_config() except the one in send_pack_config() > handles the return value of git_gpg_config(). Also handle the return value > there. > > Signed-off-by: Stefan Beller > --- > builtin/send-pack.c | 3 ++- > 1 file changed, 2 insertions(+), 1

Re: State of NewHash work, future directions, and discussion

brian m. carlson wrote: > On Mon, Jun 11, 2018 at 12:01:03PM -0700, Jonathan Nieder wrote: >> 1. Hash to be used for command output to the terminal >> 2. Hash used in pack files >> 3. Additional hashes (beyond (2)) that we can look up using the >> translation tab

Re: Hash algorithm analysis

Hi, brian m. carlson wrote: > == Discussion of Candidates > > I've implemented and tested the following algorithms, all of which are > 256-bit (in alphabetical order): Thanks for this. Where can I read your code? [...] > I also rejected some other candidates. I couldn't find any reference or

Re: State of NewHash work, future directions, and discussion

Hi, brian m. carlson wrote: > Since there's been a lot of questions recently about the state of the > NewHash work, I thought I'd send out a summary. Yay! [...] > I plan on introducing an array of hash algorithms into struct repository > (and wrapper macros) which stores, in order, the output h

[PATCH] completion: correct zsh detection when run from git-completion.zsh (Re: [PATCH v2] completion: reduce overhead of clearing cached --options)

git-completion.bash:354: read-only variable: QISUFFIX zsh:12: command not found: ___main zsh:15: _default: function definition file not found _dispatch:70: bad math expression: operand expected at `/usr/bin/g...' Segmentation fault Reported-by: Rick van Hattem Reported-by: Dave Borowitz S

Re: GDPR compliance best practices?

Hi, Peter Backes wrote: > I'd like to ask whether anyone has best practices for achieving GDPR > compliance for git repos? The GDPR will come into effect in the EU next > month. This is a reasonable question to ask other Git users on this list to share ideas, so thanks for asking it. > In parti

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

SZEDER Gábor wrote: > On Fri, Jun 8, 2018 at 11:23 PM, Jonathan Nieder wrote: >>> + [[ -z "${GIT_SOURCING_ZSH_COMPLETION}" ]] ; then >> >> Needs a - before the } to avoid errors in a shell where the user has >> chosen to use "set -u". See

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

-z "$script" ]; then > test -f $e && script="$e" && break > done > fi > -ZSH_VERSION='' . "$script" > +GIT_SOURCING_ZSH_COMPLETION=y . "$script" > > __gitcomp () > { Except for that tweak, Reviewed-by: Jonathan Nieder Thanks. Now it just needs a commit message. :)

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

str=/usr/bin/git [[ -n /usr/bin/git ]] service=_dispatch:70: bad math expression: operand expected at `/usr/bin/g...' zsh: segmentation fault zsh Here's a minimal fix, untested. As a followup, as Gábor suggests at [2], it would presumably make sense to stop

Re: [PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh

Hi, Rick van Hattem wrote: > On 4 June 2018 at 05:40, Junio C Hamano wrote: >> Overlong line, lack of sign-off. > > Apologies for the long lines, I wrote the message on Github where this > message is properly formatted, apparently the submitgit script can be > considered broken as it truncates t

Re: [PATCH 6/6] fetch-pack: introduce negotiator API

rs as common. > + In some cases, it is desirable to mark only the ancestors (for example > + when only the server does not yet know that they are common). > +*/ Not about this change: comments should have ' *' at the start of each line (could do in a preparatory patch or a followup). [...] > --- /dev/null > +++ b/negotiator/default.h > @@ -0,0 +1,8 @@ > +#ifndef NEGOTIATOR_DEFAULT_H > +#define NEGOTIATOR_DEFAULT_H > + > +#include "fetch-negotiator.h" > + > +void default_negotiator_init(struct fetch_negotiator *negotiator); optional: same question about whether to use a forward declaration as in fetch-negotiator.h. Except where noted above, Reviewed-by: Jonathan Nieder Thanks for a nice cleanup.

Re: [PATCH 5/6] fetch-pack: move common check and marking together

of how the information about common commits is stored more straightforward. No visible change intended. > Signed-off-by: Jonathan Tan > --- > fetch-pack.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) With or without such a clarification, Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH 4/6] fetch-pack: make negotiation-related vars local

Jonathan Tan wrote: > Reduce the number of global variables by making the priority queue and > the count of non-common commits in it local, passing them as a struct to > various functions where necessary. \o/ > This also helps in the case that fetch_pack() is invoked twice in the > same process

Re: [PATCH 3/6] fetch-pack: in protocol v2, enqueue commons first

Hi, Jonathan Tan wrote: > In do_fetch_pack_v2(), rev_list_insert_ref_oid() is invoked before > everything_local(). This means that if we have a commit that is both our > ref and their ref, it would be enqueued by rev_list_insert_ref_oid() as > SEEN, and since it is thus already SEEN, everything_l

Re: [PATCH 2/6] fetch-pack: truly stop negotiation upon ACK ready

Jonathan Nieder wrote: > Jonathan Tan wrote: >> The corresponding code for protocol v2 in process_acks() does not have >> the same problem, because the invoker of process_acks() >> (do_fetch_pack_v2()) proceeds immediately to processing the packfile > > nit: s/proc

Re: [PATCH 2/6] fetch-pack: truly stop negotiation upon ACK ready

Hi, Jonathan Tan wrote: > When "ACK %s ready" is received, find_common() clears rev_list in an > attempt to stop further "have" lines from being sent [1]. This appears > to work, despite the invocation to mark_common() in the "while" loop. Does "appears to work" mean "works" or "doesn't work but

Re: [PATCH 1/6] fetch-pack: clear marks before everything_local()

Hi, Jonathan Tan wrote: > If tag following is required when using a transport that does not > support tag following, fetch_pack() will be invoked twice in the same > process, necessitating a clearing of the object flags used by > fetch_pack() sometime during the second invocation. This is current

Re: [PATCH] docs: link to gitsubmodules

Jonathan Nieder wrote: > --- i/Documentation/config.txt > +++ w/Documentation/config.txt > @@ -3327,13 +3327,13 @@ submodule..ignore:: > submodule..active:: > Boolean value indicating if the submodule is of interest to git > commands. This config option takes p

Re: [PATCH] docs: link to gitsubmodules

mands like "git checkout --recurse-submodules" instead of "git submodule init". With or without that tweak, Reviewed-by: Jonathan Nieder Tested using make -C Documentation/ git-config.1 man Documentation/git-config.1 Thanks, Jonathan diff --git i/Documentati

Re: [PATCH] fetch: do not pass ref-prefixes for fetch by exact SHA1

Junio C Hamano wrote: > Jonathan Nieder writes: >> This patch adds a test to check this behavior that notices another >> behavior difference between protocol v0 and v2 in the process. Add a >> NEEDSWORK comment to clear it up. > > Thanks. > > I wonder if there

[PATCH] fetch: do not pass ref-prefixes for fetch by exact SHA1

he process. Add a NEEDSWORK comment to clear it up. Signed-off-by: Jonathan Nieder --- Here's the change described in https://public-inbox.org/git/20180531010739.gb36...@aiede.svl.corp.google.com/ as a proper patch. Thoughts of all kinds welcome, as always. refspec.c | 2 ++ re

Re: [PATCH 1/2] refspec: consolidate ref-prefix generation logic

Jonathan Nieder wrote: > Brandon Williams wrote: >> When using protocol v2 a client constructs a list of ref-prefixes which >> are sent across the wire so that the server can do server-side filtering >> of the ref-advertisement. The logic that does this exists for both &g

Re: [PATCH 1/2] refspec: consolidate ref-prefix generation logic

Hi, Brandon Williams wrote: > When using protocol v2 a client constructs a list of ref-prefixes which > are sent across the wire so that the server can do server-side filtering > of the ref-advertisement. The logic that does this exists for both > fetch and push (even though no push support for

Re: [PATCH] README: note git-secur...@googlegroups.com

he first place > to go looking for it. > > Use the same wording as we already have on the git-scm.com website and > in the man page. > > Signed-off-by: Thomas Gummerer > --- > README.md | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Jonathan Ni

Re: [PATCH 1/2] diff: turn --ita-invisible-in-index on by default

git add -N new-file git diff HEAD Before: shows addition of the new file After: shows no change Noticed because the new --ita-invisible-in-index default broke a script using "git diff --name-only --diff-filter=A master" to get a list of added files. Arguably that script shoul

Re: [PATCH 1/2] diff: turn --ita-invisible-in-index on by default

Hi Duy, Nguyễn Thái Ngọc Duy wrote: > Due to the implementation detail of intent-to-add entries. The current > "git diff" (i.e. no treeish or --cached argument) would show the > changes in the i-t-a file, but it does not mark the file as new, while > "diff --cached" would mark the file as new whi

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

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

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

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

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

url, CURLOPT_URL, p->service_url); Can this get a test? I'm particularly interested in it since it's easy to accidentally apply this patch to the wrong duplicated place (luckily 'p' is a different variable name than 'rpc' but it's an easy mistake to make if applying the patch manually). With or without such a test, Reviewed-by: Jonathan Nieder

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

ge and the test per > Jonathan's suggestion. > > http.c | 2 +- > remote-curl.c | 2 +- > t/t5551-http-fetch-smart.sh | 13 + > 3 files changed, 11 insertions(+), 6 deletions(-) Reviewed-by: Jonathan Nieder Thanks for fixing

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

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

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

Hi, Stefan Beller wrote: > On Mon, May 21, 2018 at 4:40 PM, Brandon Williams wrote: >> Configure curl to accept all encoding which curl supports instead of >> only accepting gzip responses. > > This partially reverts aa90b9697f9 (Enable info/refs gzip decompression > in HTTP client, 2012-09-19),

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

Hi, Brandon Williams wrote: > Subject: remote-curl: accept all encoding supported by curl nit: s/encoding/encodings > Configure curl to accept all encoding which curl supports instead of > only accepting gzip responses. Likewise. > This is necessary to fix a bug when using an installation of

Re: which files are "known to git"?

Hi, Robert P. J. Day wrote: > i did a quick search for that phrase in the current code base and > came up with: > > builtin/difftool.c: /* The symlink is unknown to Git so read from > the filesystem */ > dir.c:error("pathspec '%s' did not match any file(s) known to >

<    1   2   3   4   5   6   7   8   9   10   >