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

- 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 insertions(+), 3 deletions

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

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. Thanks for the careful analysis

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

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 fix; p

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

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 ratelimiti

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

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

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

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

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

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

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

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

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

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(>remote->fetch, _prefixes); > > if (ref_prefixes.argc && > - (tags == TAGS_SET ||

Re: de-alphabetizing the documentation

eful 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" to get a shorter list of commands as a starting point. Ba

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

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

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

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

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

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

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 doesn't pass

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

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

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

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

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 Signed-off-by: Jonathan Ni

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

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

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

n: 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 overriding ZSH_VERSION, using this GIT_ scoped variable everywhere instead. Thoughts? Reported-by: Rick van

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

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

t; +*/ 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,

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

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

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 tak

Re: [PATCH] docs: link to gitsubmodules

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/Documentation/co

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

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 ++ refspec.h

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 <t.gumme...@gmail.com> > --- > README.md | 3 +++ > 1 file changed, 3 insertions(+) Reviewed

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

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 should use diff-index instead, which would have sidestepped the i

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

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 <bmw...@google.com> > --- > Documentation/config.txt | 2 ++ > 1 file changed, 2 insertion

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

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

curl_easy_setopt(slot->curl, 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 <jrnie...@gmail.com>

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

Version 2 of this series just tweaks the commit message 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(-) Review

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 >

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

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

Re: which files are "known to git"?

Robert P. J. Day wrote: > On Mon, 21 May 2018, Elijah Newren wrote: >> Hi Robert, >> >> I had always assumed prior to your email that 'known to Git' meant >> 'tracked' or 'recorded in the index'... > > i *know* i've been in this discussion before, but i don't remember > where, i *assume* it was

Re: issues(?) installing git-lfs via fedora "dnf" command

Hi, Robert P. J. Day wrote: > On Mon, 21 May 2018, Jonathan Nieder wrote: >> The packager should be able to find out whether it's an issue in >> git-lfs upstream and report it to that project if it is. Git-lfs is >> not part of git.git; it's a separate project: >> htt

Re: issues(?) installing git-lfs via fedora "dnf" command

Robert P. J. Day wrote: > $ sudo dnf install git-lfs [...] > Running transaction > Preparing: > Installing : git-lfs-2.4.0-1.fc28.x86_64 > Running scriptlet: git-lfs-2.4.0-1.fc28.x86_64 > Error: Failed to call git rev-parse --git-dir --show-toplevel: "fatal: >

Re: [PATCH] git-submodule.sh: try harder to fetch a submodule

Stefan Beller wrote: > I'll resend it with a warning (using say()). Thanks, makes sense. > I think we have 2 bugs and this is merely fixing the second bug. I'm fearing that there are more than two. [...] > $ git init confused-head > $ (cd confused-head && git branch test \ > $(git

Re: [PATCH] git-submodule.sh: try harder to fetch a submodule

Hi, Stefan Beller wrote: > This is the logical continuum of fb43e31f2b4 (submodule: try harder to > fetch needed sha1 by direct fetching sha1, 2016-02-23) and fixes it as > some assumptions were not correct. Interesting. I think what would help most is an example set of commands I can use to

Re: [PATCH] sha1dc: fix for compiling on AIX using IBM XLC compiler

(cc-ing Marc Stevens for real this time. Sorry for the noise) Ævar Arnfjörð Bjarmason wrote: > On Wed, May 09 2018, jens persson wrote: >> Hello, first patch. I'm having trouble compiling on AIX using IBMs >> compiler, leading to >> unusable binaries. The following patch solved the problem for

Re: [PATCH] sha1dc: fix for compiling on AIX using IBM XLC compiler

(+cc: Marc Stevens) Ævar Arnfjörð Bjarmason wrote: > On Wed, May 09 2018, jens persson wrote: >> Hello, first patch. I'm having trouble compiling on AIX using IBMs >> compiler, leading to >> unusable binaries. The following patch solved the problem for 2.17.0. >> The patch below is cut via gmail

Re: Implementing reftable in Git

Carlos Martín Nieto wrote: > On Wed, 2018-05-09 at 09:48 -0700, Jonathan Nieder wrote: >> If you would like the patches at https://git.eclipse.org/r/q/topic:reftable >> relicensed for Git's use so that you don't need to include that >> license header, let me know. Se

Re: Implementing reftable in Git

Stefan Beller wrote: > * We *might* be able to use reftables in negotiation later > ("client: Last I fetched, you said your latest transaction > number was '5' with the hash over all refs to be ; > server: ok, here are the refs and the pack, you're welcome"). Do you mean that reftable's

Re: Implementing reftable in Git

Hi, Christian Couder wrote: > I might start working on implementing reftable in Git soon. Yay! [...] > So I think the most straightforward and compatible way to do it would > be to port the JGit implementation. I suspect following the spec[1] would be even more compatible, since it would

[PATCH 2/2 v2] Makefile: quote $INSTLIBDIR when passing it to sed

IR@@=/usr/l ...": unescaped newline inside substitute pattern Add back the missing double-quotes to make it work again. Improved-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- Hi, Junio C Hamano wrote: > Jonathan Nieder <jrnie...@gma

[PATCH 2/2] Makefile: quote $INSTLIBDIR when passing it to sed

IR@@=/usr/l ...": unescaped newline inside substitute pattern Add back the missing double-quotes to make it work again. Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- Thanks for reading. Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Mak

[PATCH 1/2] Makefile: remove unused @@PERLLIBDIR@@ substitution variable

-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- An unrelated cleanup noticed while looking over this code. Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/Makefile b/Makefile index 154929f1c8..8f4cb506ff 100644 --- a/Makefile ++

[PATCH dj/runtime-prefix 0/2] Handle $IFS in $INSTLIBDIR

ot;'=g' \ > -e 's=@@GITEXECDIR@@=$(gitexecdir_relative_SQ)=g' \ > -e 's=@@PERLLIBDIR@@=$(perllibdir_relative_SQ)=g' \ I just ran into this. Here's a pair of patches to fix it. Thanks, Jonathan Nieder (2): Makefile: remove unused substitution variable @@PERLLIBDIR@@ Makefile: quote $INSTLIBDIR when passing it to sed Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.17.0.441.gb46fe60e1d

Re: [RFC 00/10] Make .the gitmodules file path configurable

Hi, Antonio Ospite wrote: > vcsh[1] uses bare git repositories and detached work-trees to manage > *distinct* sets of configuration files directly into $HOME. Cool! I like the tooling you're creating for this, though keep in mind that Git has some weaknesses as a tool for deployment. In

Re: [RFC/PATCH] upload-pack: disable object filtering when disabled by config

Jeff King wrote: > On Wed, Mar 28, 2018 at 01:33:03PM -0700, Jonathan Nieder wrote: >> When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12, >> 2017-12-08), it was guarded by the uploadpack.allowFilter config item >> to allow server operators to control when

[RFC/PATCH] upload-pack: disable object filtering when disabled by config

of it. NEEDSWORK: tests Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- Noticed while reviewing the corresponding JGit code. If this change seems like a good idea, I can add tests and re-send it for real. Thanks, Jonathan Documentation/config.txt | 2 +- upload-pack.c| 8 2

Re: [PATCH] branch: implement shortcut to delete last branch

Hi, Aaron Greenberg wrote: > This patch gives git-branch the ability to delete the previous > checked-out branch using the "-" shortcut. This shortcut already exists > for git-checkout, git-merge, and git-revert. A common workflow is > > 1. Do some work on a local topic-branch and push it to a

Re: [PATCH v3] git{,-blame}.el: remove old bitrotting Emacs code

Hi, Ævar Arnfjörð Bjarmason wrote[1]: > The git-blame.el mode has been superseded by Emacs's own > vc-annotate (invoked by C-x v g). Users of the git.el mode are now > much better off using either Magit or the Git backend for Emacs's own > VC mode. > > These modes were added over 10 years ago

Re: get commit ID from a tree object ID

Hi, Stefan Beller wrote: > On Sat, Mar 17, 2018 at 10:57 AM Junio C Hamano wrote: >> Jeff King writes: >>> If you want to dig further, you can use the diff machinery to show which >>> commit introduced a particular tree, like: >>> >>> git rev-list --all |

Including object type and size in object id (Re: Git Merge contributor summit notes)

(administrivia: please omit parts of the text you are replying to that are not relevant to the reply. This makes it easier to see what you're replying to, especially in mail readers that don't hide quoted text by the default) Hi Jeff, Jeff Hostetler wrote: [long quote snipped] > While we are

Per-object encryption (Re: Git Merge contributor summit notes)

Hi Ævar, Ævar Arnfjörð Bjarmason wrote: > It occurred to me recently that once we have such a layer it could be > (ab)used with some relatively minor changes to do any arbitrary > local-to-remote object content translation, unless I've missed something > (but I just re-read

Re: [PATCH v3] json_writer: new routines to create data in JSON format

g...@jeffhostetler.com wrote: > From: Jeff Hostetler > > Add basic routines to generate data in JSON format. > > Signed-off-by: Jeff Hostetler If I understand the cover letter correctly, this is a JSON-like format, not actual JSON. Am I

Re: [PATCH v3] routines to generate JSON data

Hi, g...@jeffhostetler.com wrote: > From: Jeff Hostetler > > This is version 3 of my JSON data format routines. > > This version addresses the variable name changes in [v2] and adds additional > test cases. I also changed the BUG() calls to die() to help with testing.

Re: What's cooking in git.git (Mar 2018, #03; Wed, 14)

Hi, Junio C Hamano wrote: > Jonathan Tan writes: >> On Wed, 14 Mar 2018 18:34:49 -0700 >> Junio C Hamano wrote: >>> * sb/object-store (2018-03-05) 27 commits >> >> [snip list of commits] >> >>> (this branch is used by sb/packfiles-in-repository;

Re: getting fatal error trying to open git gui

Briggs, John wrote: > Jonathan Nieder wrote: >> Briggs, John wrote: >>> I just installed git for windows 10 and am getting "git-gui: fatal >>> error" "Cannot parse Git version string. >>> >>> When I execute "git vers

Re: getting fatal error trying to open git gui

Hi, Briggs, John wrote: > I just installed git for windows 10 and am getting "git-gui: fatal error" > "Cannot parse Git version string. > > When I execute "git version" in the command prompt I get > Git version 2.16.2.windows.1 > > Everything else seems to be working. How can I get the gui to

Re: [PATCH] http: fix an unused variable warning for 'curl_no_proxy'

e? Especially the error message can be very useful. With or without such a commit message tweak, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> This variable has been unused in the old-curl case since it was introduced in v2.8.0-rc2~2^2 (http: honor no_http env variable to bypass proxy, 2016-0

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