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: &g

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

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

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 2.1

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&pasted via

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

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 ref

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 force

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

: sed: 1: "s=@@INSTLIBDIR@@=/usr/l ...": unescaped newline inside substitute pattern Add back the missing double-quotes to make it work again. Improved-by: Junio C Hamano Signed-off-by: Jonathan Nieder --- Hi, Junio C Hamano wrote: > Jonathan Nieder writes: >>

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

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

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

-by: Junio C Hamano Signed-off-by: Jonathan Nieder --- 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 +++ b/Makefile @@ -2109,7 +2109,6 @@ GIT-PERL-HEADER

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

-e 's=@@INSTLIBDIR@@='"$$INSTLIBDIR"'=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 partic

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

advertisement of it. NEEDSWORK: tests Signed-off-by: Jonathan Nieder --- 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

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

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 whe

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 | >>> git diff-tree --stdin --pretty=

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 hash-function-transiti

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 understanding correctly? What are the requirements for c

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. Can the information below

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; uses >>> nd/remove-ignore-env-field.) >>> >>>

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 wo

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

e very useful. With or without such a commit message tweak, Reviewed-by: Jonathan Nieder 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-02-29). Thanks for fixing it. Sincerely, Jonathan > ATB

Re: [PATCH] Documentation/githooks: Clarify the behavior of post-checkout hook

Hi, Magne Land wrote: > From: Magne Land > > This can happen when using 'git rebase -i’: > could not detach HEAD > > Based on discovering this Stack Overflow discussion: > https://stackoverflow.com/questions/25561485/git-rebase-i-with-squash-cannot-detach-head > --- > Documentation/githooks.txt

Re: allow "~" to be present in a tag name

Hi Michal, Michal Novotny wrote: > currently, if I try to create a tag that has tilde "~" in name, an > error is raised. E.g. > > $ git tag rpkg-util-1.4~rc1 > fatal: 'rpkg-util-1.4~rc1' is not a valid tag name. As Ævar mentioned, this is disallowed to prevent a collision with Git's revision sp

Re: Opinions on changing add/add conflict resolution?

Hi, Elijah Newren wrote: > However, my question here about what to write to the working tree for > a rename/rename(2to1) conflict in one particular corner case still > remains. Should a two-way merge be performed even if it may result in > nested sets of conflict markers, or is that a sufficient

Re: [PATCH 3/3] shortlog: do not accept revisions when run outside repo

Martin Ågren wrote: > On 13 March 2018 at 20:56, Jonathan Nieder wrote: >> Martin Ågren wrote: >>> (So yes, after >>> this patch, we will still silently ignore stdin for confused usage such >>> as `git

Re: [PATCH 3/3] shortlog: do not accept revisions when run outside repo

Hi, Martin Ågren wrote: > If we are outside a repo and have any arguments left after > option-parsing, `setup_revisions()` will try to do its job and > something like this will happen: > > $ git shortlog v2.16.0.. > BUG: environment.c:183: git environment hasn't been setup > Aborted (core dump

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

Jeff King wrote: > We could even give it an environment variable, which would allow > something like: > > tar xf maybe-evil.git.tar > cd maybe-evil > export GIT_TRUST_REPO=false > git log Interesting idea. Putting it in an envvar means it gets inherited by child processes, which if I und

Re: Opinions on changing add/add conflict resolution?

Hi, Hilco Wijbenga wrote: > On Mon, Mar 12, 2018 at 2:35 PM, Jonathan Nieder wrote: >> Interesting. I would be tempted to resolve this inconsistency the >> other way: by doing a half-hearted two-way merge (e.g. by picking one >> of the two versions of the colliding file)

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

Hi, Jeff King wrote: > On Thu, Feb 22, 2018 at 01:26:34PM -0800, Jonathan Nieder wrote: >> Keep in mind that git upload-archive (a read-only command, just like >> git upload-pack) also already has the same issues. > > Yuck. I don't think we've ever made a his

Re: Opinions on changing add/add conflict resolution?

Hi again, Elijah Newren wrote: > On Mon, Mar 12, 2018 at 11:47 AM, Jonathan Nieder wrote: >> Would this behavior be configurable or unconditional? I suspect I >> would want it turned off in my own use. >> >> On the other hand, in the case of wild difference between

Re: Opinions on changing add/add conflict resolution?

Hi, Elijah Newren wrote: > Hi everyone, > > I'd like to change add/add conflict resolution. Currently when such a > conflict occurs (say at ${path}), git unconditionally does a two-way > merge of the two files and sticks the result in the working tree at > ${path}. > > I would like to make it in

Re: recent glob expansion breakage on Windows?

+git-for-windows Hi, Laszlo Ersek wrote: > Jaben reports that git-send-email is suddenly failing to expand the > "*.patch" glob for him, at the Windows CMD prompt: > > - > E:\...>git send-email --suppress-cc=author --suppress-cc=self > --suppress-cc=cc --suppress-cc=sob --dry-run *.patch

Re: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

(cc list snipped) Hi, Eddy Petrișor wrote: > Cc: [a lot of people] Can you say a little about how this cc list was created? E.g. should "git send-email" get a feature to warn about long cc lists? > Signed-off-by: Eddy Petrișor > --- > > There are projects such as llvm/clang which use several

Re: man gittutorial: patch proposal

Hi, kalle wrote: > see attachment. Thanks for writing. A few questions: 1. Can you say a little more about the rationale for this change? E.g. is the current formatting sending a confusing message? Is the current formatting intending to use '' as quotes and using italics instead?

Re: Bug report: "Use of uninitialized value $_ in print"

y check while we're thinking about it. Here's a > series. > > [1/2]: t3701: add a test for interactive.diffFilter > [2/2]: add--interactive: detect bogus diffFilter output > > git-add--interactive.perl | 8 > t/t3701-add-interactive.sh | 20 ++++ >

Re: [PATCH v3 12/35] serve: introduce git-serve

Hi, Jeff King wrote: > I agree that would be a lot more pleasant for adding protocol features. > But I just worry that the stateful protocols get a lot less efficient. > I'm having trouble coming up with an easy reproduction, but my > recollection is that http has some nasty corner cases, because

Re: Contributor Summit planning

Lars Schneider wrote: > Thanks for starting this. I would like to propose the following topics: Cool! Do you mind starting threads for these so people who aren't there can provide input into the discussion, too? In other words, I'm imagining 1. Thread starts on mailing list 2. Contributor s

Re: [PATCH v4 13/35] ls-refs: introduce ls-refs server command

Hi, On Mon, Mar 05, 2018 at 10:21:55AM -0800, Brandon Williams wrote: > On 03/02, Jeff King wrote: >> It also accepts "refs/h*" to get "refs/heads" and "refs/hello". I think >> it's worth going for the most-restrictive thing to start with, since >> that enables a lot more server operations witho

Re: [RFC] Contributing to Git (on Windows)

we'll disagree from time to time in minor ways about particular aspects of how to change the development workflow, but the progress you've already made (e.g. via tools like SubmitGit) is a huge deal. [...] Johannes Schindelin wrote: > On Sat, 3 Mar 2018, Jonathan Nieder wrote: >> 1.

Re: [RFC] Contributing to Git (on Windows)

Derrick Stolee wrote: > Dereck Stolee wrote: > > nit: s/Dereck/Derrick/ Is my outgoing email name misspelled, or do you have > a misspelled contact info for me? A manual typo. Sorry about that. [... a bunch snipped ...] > I have a habit of being too loose in language around lawyer-speak. I s

Re: [RFC] Contributing to Git (on Windows)

Hi Dscho, Johannes Schindelin wrote: > On Sat, 3 Mar 2018, Jonathan Nieder wrote: >> Hopefully the clarifications and suggestions higher in this message >> help. If they don't, then I'm nervous about our ability to understand >> each other. > > Okay, let m

Re: [RFC] Contributing to Git (on Windows)

Hi Dscho, Johannes Schindelin wrote: >> Jonathan Nieder writes: >>> Dereck Stolee wrote: >>>> +Test Your Changes on Linux >>>> +-- >>>> + >>>> +It can be important to work directly on the [core Git >>&g

Re: Bug report: "Use of uninitialized value $_ in print"

Hi, Sam Kuper wrote: > First, background. I encountered a bug on Debian Stretch, using this > git version: > > $ git --version > git version 2.11.0 > > The bug is that in the midst of running > > git -c interactive.diffFilter="git diff --word-diff --color" add --patch > > and after having answere

Re: [RFC] Contributing to Git (on Windows)

Hi, Derrick Stolee wrote: > Now, we'd like to make that document publicly available. These steps are > focused on a Windows user, so we propose putting them in the > git-for-windows/git repo under CONTRIBUTING.md. I have a pull request open > for feedback [1]. I'll read comments on that PR or in

Re: [PATCH 2/2] parse-options: remove the unused parse_opt_commits() function

> > Signed-off-by: Ramsay Jones > --- > parse-options-cb.c | 16 > parse-options.h| 1 - > 2 files changed, 17 deletions(-) Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH 1/2] ref-filter: mark a file-local symbol as static

Hi, Ramsay Jones wrote: > Commit fcfba37337 ('ref-filter: make "--contains " less chatty if > is invalid', 2018-02-23) added the add_str_to_commit_list() > function, which causes sparse to issue a "... not declared. Should it > be static?" warning for that symbol. Thanks for catching it! > In

Re: The case for two trees in a commit ("How to make rebase less modal")

Hi, Stefan Beller wrote: > $ git hash-object --stdin -w -t commit < tree c70b4a33a0089f15eb3b38092832388d75293e86 > parent 105d5b91138ced892765a84e771a061ede8d63b8 > author Stefan Beller 1519859216 -0800 > committer Stefan Beller 1519859216 -0800 > tree 5495266479afc9a4bd9560e9feac465ed43fa63a

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

Randall S. Becker wrote: > The original thread below has details of what the original issue was and > why. It hit three tests specifically on this platform where die was invoked > (at least on one of them). Perl was invoked under the covers and the > completion code of 169 propagated back through

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

Hi, Stefan Beller wrote: > On Wed, Feb 28, 2018 at 9:57 AM, Junio C Hamano wrote: >> Wait a minute. Is that topic ever shown to work well together with >> other topics in flight and are now ready to be built upon? I had an >> impression that it is just starting to get serious reviews. > > And

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

Randall S. Becker wrote: > On February 28, 2018 12:44 PM, Jonathan Nieder wrote: >> Randall S. Becker wrote: >>> The problem is actually in git code in its test suite that uses perl >>> inline, not in my test code itself. [...] >> Can you elaborate with an ex

Re: [PATCH] protocol: treat unrecognized protocol.version setting as 0

Hi, Junio C Hamano wrote: > Jonathan Nieder writes: >> If I share my .gitconfig or .git/config file between multiple machines >> (or between multiple Git versions on a single machine) and set >> >> [protocol] >> version = 2 >> >>

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

Randall S. Becker wrote: > The problem is actually in git code in its test suite that uses perl > inline, not in my test code itself. The difficulty I'm having is > placing this appropriate so that the signal handler gets used > throughout the test suite including in the perl -e invocations. This

Re: [PATCH] protocol: treat unrecognized protocol.version setting as 0

Duy Nguyen wrote: > On Wed, Feb 28, 2018 at 8:02 AM, Brandon Williams wrote: >> On 02/27, Jonathan Nieder wrote: >>> If I share my .gitconfig or .git/config file between multiple machines >>> (or between multiple Git versions on a single machine) and

[PATCH] protocol: treat unrecognized protocol.version setting as 0

spell checking (for instance, if I put "version = v1" intending "version = 1") to warn about such settings, but this patch does not, since at least in these early days for protocol v2 it is expected for configurations that want to opportunistically use protocol v2 if available not

Re: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

Hi, Randall S. Becker wrote: > After months of arguing with some platform developers on this subject, the > perl spec was held over my head repeatedly about a few lines that are > causing issues. The basic problem is this line (test-lib-functions.sh, line > 633, still in ffa952497) > >>el

Re: [PATCH v3 34/35] remote-curl: implement stateless-connect command

Hi, Brandon Williams wrote: > Teach remote-curl the 'stateless-connect' command which is used to > establish a stateless connection with servers which support protocol > version 2. This allows remote-curl to act as a proxy, allowing the git > client to communicate natively with a remote end, sim

Re: [PATCH v3 28/35] transport-helper: introduce stateless-connect

Brandon Williams wrote: > Introduce the transport-helper capability 'stateless-connect'. This > capability indicates that the transport-helper can be requested to run > the 'stateless-connect' command which should attempt to make a > stateless connection with a remote end. Once established, the

Re: [PATCH v3 31/35] remote-curl: store the protocol version the server responded with

g a different protocol version. nit: s/fallback/fall back/ (fallback is the noun/adjective, fall back the verb) > Signed-off-by: Brandon Williams With or without that tweak, Reviewed-by: Jonathan Nieder Thanks.

Re: [PATCH v3 29/35] pkt-line: add packet_buf_write_len function

Brandon Williams wrote: > Add the 'packet_buf_write_len()' function which allows for writing an > arbitrary length buffer into a 'struct strbuf' and formatting it in > packet-line format. Makes sense. [...] > --- a/pkt-line.h > +++ b/pkt-line.h > @@ -26,6 +26,7 @@ void packet_buf_flush(struct st

Re: [PATCH v3 26/35] transport-helper: remove name parameter

ter. Once the call to 'die()' was removed the parameter > was no longer necessary but wasn't removed. Clean up 'recvline_fh()' > parameter list by removing the 'name' parameter. > > Signed-off-by: Brandon Williams > --- > transport-helper.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Nice. Reviewed-by: Jonathan Nieder

Re: [PATCH] docs/pretty-formats: fix typo '% <()' -> '%<|()'

n v1.8.3-rc0~22^2 (pretty: support %>> that steals trailing spaces, 2013-04-19) and appears to be a plain typo. Thanks for fixing it. Reviewed-by: Jonathan Nieder Thanks. > --- a/Documentation/pretty-formats.txt > +++ b/Documentation/pretty-formats.txt > @@ -202,7 +202,7 @@ endif::

Re: [PATCH v3 06/35] transport: use get_refs_via_connect to get refs

Brandon Williams wrote: > On 02/26, Jonathan Nieder wrote: >> Brandon Williams wrote: >>> +++ b/transport.c >>> @@ -230,12 +230,8 @@ static int fetch_refs_via_pack(struct transport >>> *transport, >>> args.cloning = transport

Re: [PATCH v3 02/35] pkt-line: introduce struct packet_reader

Brandon Williams wrote: > On 02/12, Jonathan Nieder wrote: >>> --- a/pkt-line.h >>> +++ b/pkt-line.h >>> @@ -111,6 +111,64 @@ char *packet_read_line_buf(char **src_buf, size_t >>> *src_len, int *size); >>> */ >>> ssize_t r

Re: [PATCH v3 22/35] upload-pack: support shallow requests

Hi, Brandon Williams wrote: > Add the 'shallow' feature to the protocol version 2 command 'fetch' > which indicates that the server supports shallow clients and deepen > requets. > > Signed-off-by: Brandon Williams > --- > Documentation/technical/protocol-v2.txt | 67 +++- > serve.

Re: [PATCH v3 18/35] fetch: pass ref patterns when fetching

rotocol v2. > > Signed-off-by: Brandon Williams > --- > builtin/fetch.c | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) Reviewed-by: Jonathan Nieder Nice. I take it that tests covering this come later in the series?

Re: [PATCH v3 14/35] connect: request remote refs using v2

Brandon Williams wrote: > Teach the client to be able to request a remote's refs using protocol > v2. This is done by having a client issue a 'ls-refs' request to a v2 > server. Yay, ls-remote support! [...] > --- a/builtin/upload-pack.c > +++ b/builtin/upload-pack.c > @@ -5,6 +5,7 @@ > #inclu

Re: [PATCH v3 14/35] connect: request remote refs using v2

Jonathan Tan wrote: > On Thu, 22 Feb 2018 13:26:58 -0500 > Jeff King wrote: >> I agree that it shouldn't matter much here. But if the name argv_array >> is standing in the way of using it, I think we should consider giving it >> a more general name. I picked that not to evoke "this must be argume

Re: [PATCH v3 10/35] protocol: introduce enum protocol_version value protocol_v2

Hi, Brandon Williams wrote: > Introduce protocol_v2, a new value for 'enum protocol_version'. > Subsequent patches will fill in the implementation of protocol_v2. > > Signed-off-by: Brandon Williams > --- Yay! [...] > +++ b/builtin/fetch-pack.c > @@ -201,6 +201,9 @@ int cmd_fetch_pack(int argc

Re: [PATCH v3 02/35] pkt-line: introduce struct packet_reader

Jonathan Nieder wrote: > Brandon Williams wrote: >> Sometimes it is advantageous to be able to peek the next packet line >> without consuming it (e.g. to be able to determine the protocol version >> a server is speaking). In order to do that introduce 'struct >

Re: [PATCH v3 06/35] transport: use get_refs_via_connect to get refs

Brandon Williams wrote: > Remove code duplication and use the existing 'get_refs_via_connect()' > function to retrieve a remote's heads in 'fetch_refs_via_pack()' and > 'git_transport_push()'. > > Signed-off-by: Brandon Williams > --- > transport.c | 18 -- > 1 file changed, 4 i

Re: [PATCH v3 02/35] pkt-line: introduce struct packet_reader

Hi, Brandon Williams wrote: > Sometimes it is advantageous to be able to peek the next packet line > without consuming it (e.g. to be able to determine the protocol version > a server is speaking). In order to do that introduce 'struct > packet_reader' which is an abstraction around the normal p

Re: [PATCH v2 12/27] serve: introduce git-serve

Hi Duy, Duy Nguyen wrote: > On Fri, Jan 26, 2018 at 6:58 AM, Brandon Williams wrote: >> + stateless-rpc >> +--- >> + >> +If advertised, the `stateless-rpc` capability indicates that the server >> +supports running commands in a stateless-rpc mode, which means that a >> +command lasts

Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

Ævar Arnfjörð Bjarmason wrote: > On Sat, Feb 24 2018, Jeff King jotted: >> I actually wonder if we should just specify that the patterns must >> _always_ be fully-qualified, but may end with a single "/*" to iterate >> over wildcards. Or even simpler, that "refs/heads/foo" would find that >> ref i

Re: [BUG] [git 2.16.1] yeeek ... my files are gone .. by git pull

Hi Marcel, Marcel 'childNo͡.de' Trautwein" wrote: > I think we have a problem … or at least I had > and I’m not quite sure if this is „working as designed“ > but I’m sure it „should not work as it did“. [...] > I wanted to clone another repository … but yeah … it’s late for me today and > I put

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

Jeff King wrote: > All of that said, I think the current code is quite dangerous already, > and maybe even broken. upload-pack may run sub-commands like rev-list > or pack-objects, which are themselves builtins. Sounds like more commands to set the IGNORE_PAGER_CONFIG flag for in git.c. Thanks

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

Jeff King wrote: > The current property is that it's safe to fetch from an > untrusted repository, even over ssh. If we're keeping that for protocol > v1, we'd want it to apply to protocol v2, as well. Ah, this is what I had been missing (the non-ssh case). I see your point. I t

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

Hi, Jeff King wrote: > On Thu, Feb 22, 2018 at 11:38:14AM -0800, Jonathan Nieder wrote: >> To be clear, which of the following are you (most) worried about? >> >> 1. being invoked with --help and spawning a pager >> 2. receiving and acting on options between &#

Re: [PATCH v3 04/35] upload-pack: convert to a builtin

Hi, Jeff King wrote: > On Thu, Feb 22, 2018 at 10:07:15AM -0800, Brandon Williams wrote: >> On 02/22, Jeff King wrote: >>> On Wed, Feb 21, 2018 at 01:44:22PM -0800, Jonathan Tan wrote: On Tue, 6 Feb 2018 17:12:41 -0800 Brandon Williams wrote: > In order to allow for code sharing w

Re: [PATCH 26/27] sha1_file: allow map_sha1_file to handle arbitrary repositories

Stefan Beller wrote: > Signed-off-by: Stefan Beller > Signed-off-by: Jonathan Nieder > --- > object-store.h | 3 +-- > sha1_file.c| 5 +++-- > 2 files changed, 4 insertions(+), 4 deletions(-) Thanks: this is short and simple, making my life as a reviewer very easy. Rev

Re: [PATCH 21/27] sha1_file: add repository argument to sha1_loose_object_info

yet. > > As with the previous commits, use a macro to catch callers passing a > repository other than the_repository at compile time. > > Signed-off-by: Stefan Beller > Signed-off-by: Jonathan Nieder > --- > sha1_file.c | 9 + > 1 file changed, 5 insertions(+),

Re: [PATCH 17/27] sha1_file: add repository argument to stat_sha1_file

. > > As with the previous commits, use a macro to catch callers passing a > repository other than the_repository at compile time. > > Signed-off-by: Stefan Beller > Signed-off-by: Jonathan Nieder > --- > sha1_file.c | 9 + > 1 file changed, 5 insertions(+), 4 deletion

Re: [PATCH 13/27] sha1_file: add repository argument to prepare_alt_odb

Hi, Stefan Beller wrote: > See previous patch for explanation. > > While at it, move the declaration to object-store.h, > where it should be easier to find. Which declaration? It looks like prepare_alt_odb is already in object-store.h. [...] > --- a/builtin/fsck.c > +++ b/builtin/fsck.c > @@ -

Re: [PATCH 05/27] object-store: move packed_git and packed_git_mru to object store

Hi, Stefan Beller wrote: > In a process with multiple repositories open, packfile accessors > should be associated to a single repository and not shared globally. > Move packed_git and packed_git_mru into the_repository and adjust > callers to reflect this. > > Patch generated by > > 1. Moving t

Re: [PATCH 01/27] repository: introduce raw object store field

rovide access to raw object content, while the higher > level object parser code will parse raw objects and keeps track of > parenthood and other object relationships using 'struct object'. > For now only add the lower level to the repository struct. > > Signed-off-by: Stefan Be

Re: bug in HTTP protocol spec

(+cc: bmwill@, who is working on protocol v2) Hi, Dorian Taylor wrote: > On Feb 21, 2018, at 2:15 PM, Jeff King wrote: >> Thanks, I agree the document is buggy. Do you want to submit a patch? > > Will this do? Thanks for writing it. Do you mind if we forge your sign-off? (See Documentation/Su

Re: Bug Report: git status triggers a file change event

+git-for-windows Hi, Raining Chain wrote: > On Windows 10, git version 2.16.2.windows.1, running the command > > git status > > will trigger a file change event to file C:\myPath\.git "Attributes changed." > > This causes problems when using scripts that detect file changes such > as tsc -w (Typ

Re: [PATCH 04/26] upload-pack: convert to a builtin

Brandon Williams wrote: > On 01/03, Stefan Beller wrote: > > On Tue, Jan 2, 2018 at 4:18 PM, Brandon Williams wrote: >>> In order to allow for code sharing with the server-side of fetch in >>> protocol-v2 convert upload-pack to be a builtin. >> >> What is the security aspect of this patch? >> >>

Re: [PATCHv2 00/16] Moving global state into the repository object (part 1)

Hi, Stefan Beller wrote: > v2: > * duplicated the 'ignore_env' bit into the object store as well > * the #define trick no longer works as we do not have a "the_objectstore" > global, > which means there is just one patch per function that is converted. > As this follows the same structure of

Re: [PATCH 3/8] perl: generalize the Git::LoadCPAN facility

Hi, Todd Zullinger wrote: > Subject: [PATCH] Makefile: add NO_PERL_CPAN_FALLBACKS to disable fallback > module install > > As noted in perl/Git/LoadCPAN.pm, operating system packages often don't > want to ship Git::FromCPAN tree at all, preferring to use their own > packaging of CPAN modules ins

Re: [PATCH 8/8] perl: hard-depend on the File::{Temp,Spec} modules

Ævar Arnfjörð Bjarmason wrote: > --- a/perl/Git.pm > +++ b/perl/Git.pm > @@ -1324,8 +1324,9 @@ sub _temp_cache { > } > > sub _verify_require { > - eval { require File::Temp; require File::Spec; }; > - $@ and throw Error::Simple($@); > + require File::Temp; > + require File::Spe

Re: [PATCH 7/8] gitweb: hard-depend on the Digest::MD5 5.8 module

Ævar Arnfjörð Bjarmason wrote: > Signed-off-by: Ævar Arnfjörð Bjarmason > --- > gitweb/INSTALL | 3 +-- > gitweb/gitweb.perl | 17 + > 2 files changed, 6 insertions(+), 14 deletions(-) Makes sense, and I like the diffstat. [...] > +++ b/gitweb/gitweb.perl [...] > @@ -1166,

Re: [PATCH 6/8] git-send-email: unconditionally use Net::{SMTP,Domain}

Ævar Arnfjörð Bjarmason wrote: > The Net::SMTP and Net::Domain were both first released with perl > v5.7.3, since my d48b284183 ("perl: bump the required Perl version to > 5.8 from 5.6.[21]", 2010-09-24) we've depended on 5.8, so there's no > reason to conditionally require this anymore. > > This

Re: [PATCH 5/8] perl: update our copy of Mail::Address

ons(-) > create mode 100644 perl/Git/FromCPAN/Mail/.gitattributes Yikes re the stripped POD with license notice. Thanks for fixing it. Reviewed-by: Jonathan Nieder

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