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

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

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

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 <jrnie...@gmail.com> wrote: >> Martin Ågren wrote: >>> (So yes, after >>> this patch, we will still silently ignore stdin for confused usage suc

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

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

Re: Opinions on changing add/add conflict resolution?

Hi, Hilco Wijbenga wrote: > On Mon, Mar 12, 2018 at 2:35 PM, Jonathan Nieder <jrnie...@gmail.com> 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 ver

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 <jrnie...@gmail.com> 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 o

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

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

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

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

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

files changed, 28 insertions(+) With or without the tweak Ævar Arnfjörð Bjarmason suggested, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks. It's probably also worth adding Sam's reported-by to patch 2/2: Reported-by: Sam Kuper <sam.ku...@uclmail.net>

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,

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

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

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

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

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

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 me

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

Hi Dscho, Johannes Schindelin wrote: >> Jonathan Nieder <jrnie...@gmail.com> writes: >>> Dereck Stolee wrote: >>>> +Test Your Changes on Linux >>>> +-- >>>> + >>>> +It can be important to wor

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

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 <ram...@ramsayjones.plus.com> > --- > parse-options-cb.c | 16 > parse-options.h| 1 - > 2 files changed, 17 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> 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

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

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 w

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

Hi, Junio C Hamano wrote: > Jonathan Nieder <jrnie...@gmail.com> 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] >> ve

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 <bmw...@google.com> wrote: >> On 02/27, Jonathan Nieder wrote: >>> If I share my .gitconfig or .git/config file between multiple machines >>> (or between multiple Git vers

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

l 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 to be unu

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

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,

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

ent protocol version. nit: s/fallback/fall back/ (fallback is the noun/adjective, fall back the verb) > Signed-off-by: Brandon Williams <bmw...@google.com> With or without that tweak, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> 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

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

ons(+), 3 deletions(-) Nice. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

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

space was introduced in 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 <jrnie...@gmail.com> Thanks. > --- a/Documentation/pretty-formats.txt > +++ b/Documentation/pre

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

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

. > > Signed-off-by: Brandon Williams <bmw...@google.com> > --- > builtin/fetch.c | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> 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 @@ >

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

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

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

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

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

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

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

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

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

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

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

Stefan Beller wrote: > Signed-off-by: Stefan Beller <sbel...@google.com> > Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> > --- > object-store.h | 3 +-- > sha1_file.c| 5 +++-- > 2 files changed, 4 insertions(+), 4 deletions(-) Thanks: this is sh

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

pository 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 <sbel...@google.com> > Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> > --- > sha1_file.c | 9

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

pository 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 <sbel...@google.com> > Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> > --- > sha1_file.c | 9 +

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

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

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

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

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

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

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

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

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

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. [...] > +++

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 <jrnie...@gmail.com>

Re: [PATCH 4/8] perl: update our ancient copy of Error.pm

Ævar Arnfjörð Bjarmason wrote: > The Error.pm shipped with Git as a fallback if there was no Error.pm > on the system was released in April 2006, there's been dozens of > releases since then, the latest at August 7, 2017, let's update to > that. Comma splices: s/, there's/. There's/ s/,

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

Ævar Arnfjörð Bjarmason wrote: > Change the two wrappers to load from CPAN (local OS) or our own copy > to do so via the same codepath. nit: I think with s/to load/that load/ this will be easier to read. > I added the Error.pm wrapper in 20d2a30f8f ("Makefile: replace > perl/Makefile.PL with

Re: [PATCH 2/8] perl: move CPAN loader wrappers to another namespace

so makes things a bit less confusing since there was already a > Git::Error namespace ever since 8b9150e3e3 ("Git.pm: Handle failed > commands' output", 2006-06-24). > > Signed-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> Makes sense. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH 1/8] perl: *.pm files should not have the executable bit

d-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> With or without such a tweak, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

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

Hi, Stefan Beller wrote: > This is a real take on the first part of the recent RFC[1]. > > Jonathan Tan suggested[2] that "sha1_loose_object_info to handle arbitrary > repositories" > might be a good breaking point for a first part at that RFC at patch 38. > This series is smaller and contains

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

Hi, Brandon Williams wrote: > Subject: pkt-line: introduce struct packet_reader nit: this subject line doesn't describe what the purpose/intent behind the patch is. Maybe something like pkt-line: allow peeking at a packet line without consuming it would make it clearer. > Sometimes

Re: [PATCH v3 01/35] pkt-line: introduce packet_read_with_status

Hi, Brandon Williams wrote: > The current pkt-line API encodes the status of a pkt-line read in the > length of the read content. An error is indicated with '-1', a flush > with '0' (which can be confusing since a return value of '0' can also > indicate an empty pkt-line), and a positive

Re: Are concurrent git operations on the same repo safe?

Ian Norton wrote: > Specifically I'm trying to speed up "git > submodule update" by doing several at the same time. Can you say more about this? E.g. how can I reproduce your experience? Is there a script I can run? Thanks, Jonathan

Re: Missing git options

Hi, Martin Häcker wrote: >> Am 06.02.2018 um 01:43 schrieb brian m. carlson >> : >> I think this is likely to cause problems. Many people use git log with >> --pretty to format commit hashes or messages into other programs. I'm >> aware of multiple tools that

Re: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands

+cc: upstream Hi, Salvatore Bonaccorso wrote[1]: > the following vulnerability was published for git. > > CVE-2018-121[0]: > |client prints server sent ANSI escape codes to the terminal, allowing > |for unverified messages to potentially execute arbitrary commands > > Creating this bug to

Re: git: handling HTTPS proxy w/ password inappropriately

Hi, Yangfl wrote[1]: > not affected any more Can you say a little more about this? Do you mean that newer versions of Git are working better for you or that your proxy setup changed? This looks similar to

Re: [PATCH v3 1/3] read-cache: fix reading the shared index for other repos

Hi, Duy Nguyen wrote: > On Wed, Jan 17, 2018 at 4:42 AM, Brandon Williams wrote: >> IIUC Split index is an index extension >> that can be enabled to limit the size of the index file that is written >> when making changes to the index. It

Re: [PATCH v5 8/9] sequencer: try to commit without forking 'git commit'

Hi, Phillip Wood wrote: > From: Phillip Wood > > If the commit message does not need to be edited then create the > commit without forking 'git commit'. Taking the best time of ten runs > with a warm cache this reduces the time taken to cherry-pick 10 > commits by

Re: upstreaming https://github.com/cgwalters/git-evtag ?

Hi, Santiago Torres wrote: >> In contrast, working on hash-function-transition.txt? That >> seems like it'd easily consume many person-months of work. >> And that plan only exists post-shatter.io, whereas git-evtag >> long predates both. > > I think this is partly true. A hash transition has

Re: Can't squash merge with merge.ff set to false

Hi, Robert Dailey wrote: > Not sure if this is intended or a bug, but with the following configuration: > > $ git config --global merge.ff false > > I am not able to merge my topic branch into master with squash option: > > $ git checkout master > $ git merge --squash topic > fatal: You cannot

Re: [ANNOUNCE] Git v2.16.0-rc0

Bryan Turner wrote: > On Tue, Jan 2, 2018 at 9:07 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: >> So my first question is why the basename detection is not working for >> you. What value of GIT_SSH, GIT_SSH_COMMAND, or core.sshCommand are >> you using? >

Re: [ANNOUNCE] Git v2.16.0-rc0

Hi, A few more notes. Bryan Turner wrote: > bturner@ubuntu:~$ ssh -V > OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f 6 Jan 2014 > > bturner@ubuntu:~$ ssh -G -p 7999 localhost > unknown option -- G > usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [...] > Is it

Re: [ANNOUNCE] Git v2.16.0-rc0

Hi Bryan, Bryan Turner wrote: > Our test environment is still on Ubuntu 12.04 LTS (it's a long story, > but one I doubt is unique to us), which means it's using OpenSSH 5.9. > ssh -G was added in OpenSSH 6.8 [1], circa March 2015, which means the > "auto" detection "fails" and chooses "simple"

Re: What's cooking in git.git (Dec 2017, #05; Wed, 27)

Stefan Beller wrote: > On Thu, Dec 28, 2017 at 11:02 AM, Junio C Hamano wrote: >> Elijah Newren writes: >>> surprised by the branch name, though. Was 'ew/' a typo, >> >> Blush X-<. Yes it is a typo. > > Note on that series: > I have reviewed the first

Re: [PATCH v2 1/5] core.aheadbehind: add new config setting

Hi, Jeff Hostetler wrote: > On 12/21/2017 3:43 PM, Jonathan Nieder wrote: >> I also wonder if there's a way to achieve the same benefit without >> having it be configurable. E.g. if a branch is way behind, couldn't >> we terminate the walk early to get the same bo

[PATCH ab/simplify-perl-makefile] perl: treat PERLLIB_EXTRA as an extra path again (Re: [PATCH v6] Makefile: replace perl/Makefile.PL with simple make rules)

vior. Restore the previous code structure to make PERLLIB_EXTRA work again. Reproducing this problem requires an invocation of "make install" instead of running bin-wrappers/git in place, since the latter sets the GITPERLLIB environment variable, avoiding trouble. Reported-by: Jonathan Kore

Re: [PATCH v6] Makefile: replace perl/Makefile.PL with simple make rules

Hi, Ævar Arnfjörð Bjarmason wrote: > +++ b/Makefile [...] > -PERL_DEFINES = $(PERL_PATH_SQ):$(PERLLIB_EXTRA_SQ) > -$(SCRIPT_PERL_GEN): % : %.perl perl/perl.mak GIT-PERL-DEFINES > GIT-VERSION-FILE > +PERL_DEFINES = $(PERL_PATH_SQ):$(PERLLIB_EXTRA_SQ):$(perllibdir_SQ) > +$(SCRIPT_PERL_GEN): % :

Re: [PATCH v2 2/2] Windows: stop supplying BLK_SHA1=YesPlease by default

g that was missed back in > e6b07da278 ("Makefile: make DC_SHA1 the default", 2017-03-17). micronit: the commas should be periods. With or without such a tweak, this is indeed Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [PATCH v2 1/2] Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1

A1 implementation will be used. > > Signed-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> > Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> This is indeed Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks for your patient work.

Re: [PATCH 1/2] travis-ci: don't try to create the cache directory unnecessarily

SZEDER Gábor wrote: > On Wed, Dec 27, 2017 at 8:46 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > > SZEDER Gábor wrote: >>> Travis CI creates that directory for us anyway, even when a previous >>> cache doesn't exist for the current build job. >>

Re: [PATCH 2/2] Windows: stop supplying BLK_SHA1=YesPlease by default

+git-for-windows Ævar Arnfjörð Bjarmason wrote: > Using BLK_SHA1 in lieu of the OpenSSL routines was done in [1], but > since DC_SHA1 is now the default for git in general it makes sense for > Windows to use that too, this looks like something that was missed > back in [2]. > > As noted in [3]

Re: [PATCH 1/2] Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1

# a bundled SHA1 routine optimized for PowerPC. > # > # Define NO_OPENSSL environment variable if you do not have OpenSSL. > -# This also implies BLK_SHA1. With or without some of those commit message tweaks Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks, Jonathan

Re: [PATCH 1/2] travis-ci: don't try to create the cache directory unnecessarily

SZEDER Gábor wrote: > Travis CI creates that directory for us anyway, even when a previous > cache doesn't exist for the current build job. > > In itself it doesn't hurt to try, of course, but the following patch > will access the Travis CI cache much earlier in the build process, and > then

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