Re: [RFC PATCH 3/3] sha1_file: add promised blob hook support

Hi, Ben Peart wrote: > On 7/11/2017 3:48 PM, Jonathan Tan wrote: >> Teach sha1_file to invoke a hook whenever a blob is requested and >> unavailable but is promised. The hook is a shell command that can be >> configured through "git config"; this hook takes in a list of hashes and >> writes (if

Re: [RFC PATCH 1/3] promised-blob, fsck: introduce promised blobs

Hi, Jeff Hostetler wrote: > My primary concern is scale and managing the list of objects over time. [...] > For > example, on the Windows repo we have (conservatively) 100M+ blobs (and > growing). Assuming 28 bytes per, gives a

Re: [PATCH 0/3] Convert grep to recurse in-process

Jeff King wrote: > On Wed, Jul 12, 2017 at 11:06:03AM -0700, Brandon Williams wrote: >> Each 'struct repository' does have its own config so we could >> potentially want a config in a submodule to override some config in the >> superproject. Though for right now it may be simpler to not worry

Re: [PATCH 0/3] Convert grep to recurse in-process

Hi, Jeff King wrote: > I didn't follow the rest of the "struct repository" series closely, but > I don't feel like we ever reached a resolution on how config would be > handled. I notice that the in-process "ls-files" behaves differently > than the old one when config differs between the

Re: [PATCH 3/3] grep: recurse in-process using 'struct repository'

Hi, Brandon Williams wrote: > Convert grep to use 'struct repository' which enables recursing into > submodules to be handled in-process. \o/ This will be even nicer with the changes described at https://public-inbox.org/git/20170706202739.6056-1-sbel...@google.com/. Until then, I fear it will

Re: [PATCH 2/3] setup: have the_repository use the_index

Hi, Brandon Williams wrote: > Have the index state which is stored in 'the_repository' be a pointer to > the in-core instead 'the_index'. This makes it easier to begin > transitioning more parts of the code base to operate on a 'struct > repository'. > > Signed-off-by: Brandon Williams

Re: [PATCH 1/3] repo_read_index: don't discard the index

hanged, 2 deletions(-) How did you discover this? E.g. was it from code inspection or does this make the function more convenient to use for some kinds of callers? Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH 2/2] hashmap: migrate documentation from Documentation/technical into header

Stefan Beller wrote: > Subject: hashmap: migrate documentation from Documentation/technical into > header > > While at it, clarify the use of `key`, `keydata`, `entry_or_key` as well > as documenting the new data pointer for the compare function. > > Signed-off-by: Stefan Beller

Re: RFC: Missing blob hook might be invoked infinitely recursively

Hi, Jonathan Tan wrote: > Suppose you have missing blob AB12 and CD34 that you now need, so > fetch-blob is invoked. It sends the literals AB12 and CD34 to a new > server endpoint and obtains a packfile, which it then pipes through "git > index-pack". The issue is that "git index-pack" wants to

Re: [PATCH 1/1] ls-remote: remove "-h" from help text

Hi, Silvio Fricke wrote: > This regression was fixed in 91a640ffb6d9 ("ls-remote: a lone "-h" is > asking for help") and the wrong help text was introduced in ba5f28bf79ea > ("ls-remote: use parse-options api"). > This patch removes the "-h" on the help text. > > Signed-off-by: Silvio Fricke

"git push --recurse-submodules=on-demand" regression

From: evandrocoan Originally posted on: https://github.com/git-for-windows/git/issues/1212 My git version is: git --version --build-options git version 2.13.0.windows.1 built from commit: eba7af3dbb4c846c6303c5f64102acee696c9ab0 sizeof-long: 4 machine: x86 cmd.exe /c

Re: [PATCH] pack-bitmap: Don't perform unaligned memory access

gned-off-by: James Clarke <jrt...@jrtc27.com> > --- > pack-bitmap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Failing build log: https://buildd.debian.org/status/fetch.php?pkg=git=sparc64=1%3A2.13.2-2=1498520310=0 Thanks for tracking down and fixing it.

Re: Monitoring a repository for changes

Hi, Tim Hutt wrote: > Currently if you want to monitor a repository for changes there are > three options: > > * Polling - run a script to check for updates every 60 seconds. > * Server side hooks > * Web hooks (on Github, Bitbucket etc.) > > Unfortunately for many (most?) cases server-side

Re: [PATCH v3 11/20] path: construct correct path to a worktree's index

Brandon Williams wrote: > So your suggestion is to completely avoid doing any location when asking > for a worktree_git_path, I guess those code paths which request those > paths should be aware enough that if they need something in commondir to > use git_common_path instead. My only worry is

Re: [PATCH v3 11/20] path: construct correct path to a worktree's index

[jn: rewrote commit message; skipping all relocation instead of just GIT_INDEX_FILE] Signed-off-by: Brandon Williams <bmw...@google.com> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- Jonathan Nieder wrote: > How about the following? I found it a little easier to unde

Re: [PATCH v3 11/20] path: construct correct path to a worktree's index

ditionally instead of based on whether environment or configuration variables are set, causing the relocation to trigger even when GIT_INDEX_FILE is not set. [jn: rewrote commit message; skipped all relocations instead of just the index] Change-Id: I2ba0a48a48b7e9a9c2e3ef97648cf53cb913bdd9 Sign

Re: [PATCH v3 11/20] path: construct correct path to a worktree's index

Hi, Brandon Williams wrote: > When working with worktrees the git directory is split into two part, > the per-worktree gitdir and a commondir which contains things which are > shared among all worktrees (like the object store). With this notion of > having a split git directory, 557bd833b

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Junio C Hamano wrote: > Junio C Hamano writes: >> Adam Langley writes: >>> However, as I'm not a git developer, I've no opinion on whether the >>> cost of carrying implementations of these functions is worth the speed >>> vs using SHA-256, which can be

Re: [PATCHv5 2/2] Documentation/clone: document ignored configuration variables

Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 16 2017, SZEDER Gábor jotted: >> --- a/Documentation/git-clone.txt >> +++ b/Documentation/git-clone.txt >> @@ -186,6 +186,11 @@ objects from the source repository into a pack in the >> cloned repository. >> values are given for the same key, each

Re: [PATCHv5 1/2] clone: respect additional configured fetch refspecs during initial fetch

1 + > t/t5611-clone-config.sh | 47 +++ > 4 files changed, 80 insertions(+), 17 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [PATCHv5 2/2] Documentation/clone: document ignored configuration variables

ables are known to be > ignored ('remote.origin.mirror' and 'remote.origin.tagOpt') under the > documentation of 'git clone -c'. > > Signed-off-by: SZEDER Gábor <szeder@gmail.com> > --- > Documentation/git-clone.txt | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH] docs/pretty-formats: stress that %- removes all preceding line-feeds

1 file changed, 2 insertions(+), 2 deletions(-) With or without such a tweak, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks. > diff --git a/Documentation/pretty-formats.txt > b/Documentation/pretty-formats.txt > index 38040e95b..a48d267e2 100644 > --- a/Documenta

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi Dscho, Johannes Schindelin wrote: > From what I read, pretty much everybody who participated in the discussion > was aware that the essential question is: performance vs security. I don't completely agree with this framing. The essential question is: how to get the right security properties

Re: [PATCH] sub-process: fix comment about api-sub-process.txt

;git log" output. > Signed-off-by: Christian Couder <chrisc...@tuxfamily.org> > --- > sub-process.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) With or without such a tweak, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> > diff --git a/sub-proc

Re: [PATCH v3] Configure Git contribution guidelines for github.com

; create mode 100644 .github/CONTRIBUTING.md > create mode 100644 .github/PULL_REQUEST_TEMPLATE.md Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: t1308-config-set.sh fails on current master

Hi Øyvind, Øyvind A. Holm wrote: > t1308-config-set.sh fails on current master (v2.13.1-449-g02a2850ad58e). > The error is introduced by commit e2d90fd1c33a ("config.mak.uname: set > FREAD_READS_DIRECTORIES for Linux and FreeBSD"). Reverting the commit > results in a conflict, but the test

Re: What's cooking in git.git (Jun 2017, #04; Tue, 13)

Jun 13, 2017 at 02:40:16PM -0700, Junio C Hamano wrote: > * sb/submodule-blanket-recursive (2017-06-01) 9 commits > (merged to 'next' on 2017-06-04 at 418bb03032) > + builtin/fetch.c: respect 'submodule.recurse' option > + builtin/push.c: respect 'submodule.recurse' option > +

Re: [PATCH] remote: drop free_refspecs() function

rder on the > parsing side. > > Signed-off-by: Jeff King <p...@peff.net> > --- > remote.c | 28 ++------ > 1 file changed, 6 insertions(+), 22 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [PATCHv4 1/2] clone: respect additional configured fetch refspecs during initial fetch

Hi, SZEDER Gábor wrote: > The initial fetch during a clone doesn't transfer refs matching > additional fetch refspecs given on the command line as configuration > variables. This contradicts the documentation stating that > configuration variables specified via 'git clone -c = ...' > "take

Re: [PATCHv4 2/2] Documentation/clone: document ignored configuration variables

Hi, SZEDER Gábor wrote: > Due to limitations/bugs in the current implementation, some > configuration variables specified via 'git clone -c var=val' (or 'git > -c var=val clone') are ignored during the initial fetch and checkout. > > Let the users know which configuration variables are known to

Re: [PATCH 8/8] t0012: test "-h" with builtins

Hi, Jeff King wrote: > --- a/t/t0012-help.sh > +++ b/t/t0012-help.sh > @@ -49,4 +49,16 @@ test_expect_success "--help does not work for guides" " > test_i18ncmp expect actual > " > > +test_expect_success 'generate builtin list' ' > + git --list-builtins >builtins > +' > + > +while

Re: [PATCH v2 4/6] config: don't implicitly use gitdir

Junio C Hamano wrote: > On Tue, Jun 13, 2017 at 2:51 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: >> What is the next step, then? You can find the notion ridiculous but >> it's how this project has worked in my experience (and how other >> projects with similar

Re: [PATCH v2 3/6] config: don't include config.h by default

1 deletion(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [PATCH v2 4/6] config: don't implicitly use gitdir

Brandon Williams wrote: > On 06/13, Jonathan Nieder wrote: >> Brandon Williams wrote: >>> Commit 2185fde56 (config: handle conditional include when $GIT_DIR is >>> not set up) added a 'git_dir' field to the config_options struct. Let's >>> use this option f

Re: [PATCH v2 2/6] config: remove git_config_iter

) Language nit: s/' lets/', let's/ That is, there is a comma and an apostrophe missing. With or without that tweak, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH v2 1/6] config: create config.h

t diff HEAD^:cache.h config.h' confirms that this is straightforward code movement and didn't introduce any unintentional changes along the way. Thanks for writing it. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH v2 4/6] config: don't implicitly use gitdir

Brandon Williams wrote: > Commit 2185fde56 (config: handle conditional include when $GIT_DIR is > not set up) added a 'git_dir' field to the config_options struct. Let's > use this option field explicitly all the time instead of occasionally > falling back to calling 'git_pathdup("config")' to

Re: [PATCH/RFC] branch: add tests for new copy branch feature

Ævar Arnfjörð Bjarmason wrote: > On Tue, Jun 13 2017, Jonathan Nieder jotted: > > Ævar Arnfjörð Bjarmason wrote: >>> My understanding of that last part is that Jonathan/someone (see >>> reported-by in that patch) had some script which was renaming >>> bran

Re: [PATCH/RFC] branch: add tests for new copy branch feature

Hi, Ævar Arnfjörð Bjarmason wrote: > So the reason we have this for -m is: > > commit 3f59481e33 > Author: Jonathan Nieder <jrnie...@gmail.com> > Date: Fri Nov 25 20:30:02 2011 -0600 > > branch: allow a no-op "branch -M HEAD" &

Re: [PATCH 4/4] config: don't implicitly use gitdir

Jeff King wrote: > On Mon, Jun 12, 2017 at 06:38:17PM -0700, Jonathan Nieder wrote: >> Brandon Williams wrote: >>> On 06/12, Jonathan Nieder wrote: >>>> Alternatively, could this patch rename git_config_with_options? That >>>> way any other patch in

Re: [PATCH 4/4] config: don't implicitly use gitdir

Hi again, Brandon Williams wrote: > On 06/12, Jonathan Nieder wrote: >> Alternatively, could this patch rename git_config_with_options? That >> way any other patch in flight that calls git_config_with_options would >> conflict with this patch, giving us an opportunity to

Re: [PATCH 4/4] config: don't implicitly use gitdir

Brandon Williams wrote: > On 06/12, Jonathan Nieder wrote: >> Brandon Williams wrote: >>> Commit 2185fde56 (config: handle conditional include when $GIT_DIR is >>> not set up) added a 'git_dir' field to the config_options struct. Let's >>> use this option f

Re: [PATCH 0/4] config.h

Brandon Williams wrote: > Brandon Williams (4): > config: create config.h > config: remove git_config_iter > config: don't include config.h by default > config: don't implicitly use gitdir Patches 1-3 are Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> I'm very

Re: [PATCH 4/4] config: don't implicitly use gitdir

Hi, Brandon Williams wrote: > Commit 2185fde56 (config: handle conditional include when $GIT_DIR is > not set up) added a 'git_dir' field to the config_options struct. Let's > use this option field explicitly all the time instead of occasionally > falling back to calling 'git_pathdup("config")'

Re: [PATCH 2/4] config: remove git_config_iter

hanged, 1 deletion(-) Good eyes. Looks like the function never existed. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> > diff --git a/config.h b/config.h > index f7f8b66c5..c70599bd5 100644 > --- a/config.h > +++ b/config.h > @@ -165,7 +165,6 @@ extern int git_configset_g

Re: [PATCH v2 1/2] git-compat-util: add a FREEZ() wrapper around free(ptr); ptr = NULL

Hi, Ævar Arnfjörð Bjarmason wrote: > Add a FREEZ() wrapper marco for the common pattern of freeing a > pointer and assigning NULL to it right afterwards. I'm conflicted. On one hand it makes code more concise and makes it easier for people to remember to assign NULL after freeing a variable.

Re: [PATCH v1] Configure Git contribution guidelines for github.com

Hi, Some mostly nitpicky initial thoughts. Thanks for writing this. Lars Schneider wrote: > Many open source projects use github.com for their contribution process. > Although we mirror the Git core repository to github.com [1] we do not > use any other github.com service. This is

Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output

Stefan Beller wrote: > On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin > wrote: >> In my mind, it would have made sense to ask well-respected cryptographers >> about their opinions and then try to figure out a consensus among them (as >> opposed to what I saw so

Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output

Hi, Johannes Schindelin wrote: > On Fri, 2 Jun 2017, Jonathan Nieder wrote: >> Johannes Schindelin wrote: >>> Maybe we should call out a specific month (or even a longer period) during >>> which we try to push toward that new hash function, and focus more on >>&

Re: [PATCH] submodule foreach: correct $sm_path in nested submodules from a dir

Hi, This patch seems to aim to do multiple things. Initial thoughts: Stefan Beller wrote: [...] > To ameliorate the situation, perform these changes > * Document 'sm_path' instead of 'path'. > As using a variable '$path' may be harmful to users due to > capitalization issues, see

Re: [WIP v2 2/2] pack-objects: support --blob-max-bytes

Jeff King wrote: > On Fri, Jun 02, 2017 at 12:38:45PM -0700, Jonathan Tan wrote: >> +--blob-max-bytes=:: >> +This option can only be used with --stdout. If specified, a blob >> +larger than this will not be packed unless a to-be-packed tree >> +has that blob with a filename beginning

Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output

Jonathan Nieder wrote: > Here's a rough list of some useful tasks, in no particular order: > > 1. bc/object-id: This patch series continues, eliminating assumptions >about the size of object ids by encapsulating them in a struct. >One straightforward way to find code t

Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output

Hi Dscho, Johannes Schindelin wrote: > On Thu, 1 Jun 2017, Stefan Beller wrote: >> We had a discussion off list how much of the test suite is in bad shape, >> and "$ git grep ^index" points out a lot of places as well. > > Maybe we should call out a specific month (or even a longer period)

[PATCH v2] send-email: Net::SMTP::starttls was introduced in v2.34 (Re: [BUG] git-send-email broken: Can't locate object method "starttls")

ia package "Net::SMTP" at /usr/lib/git-core/git-send-email line 1410. Reported-by: Brandon Williams <bmw...@google.com> Reported-and-tested-by: Eric Biggers <ebigge...@gmail.com> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- Jonathan Nieder wrote: > T

Re: [PATCH] send-email: Net::SMTP::starttls was introduced in v3.01 (Re: [BUG] git-send-email broken: Can't locate object method "starttls")

Eric Biggers wrote: > On Wed, May 31, 2017 at 03:44:15PM -0700, Jonathan Nieder wrote: >> Subject: send-email: Net::SMTP::starttls was introduced in v3.01 >> >> We cannot rely on the starttls method being present in the copy >> of Net::SMTP shipped with perl until

Re: [PATCH v2] send-email: Net::SMTP::SSL is obsolete, use only when necessary

Hi, Jun 01, 2017 at 07:39:16AM +0900, Junio C Hamano wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> This broke git send-email for me. The error message is >> >> Can't locate object method "starttls" via package "Net::SMTP" at

[PATCH] send-email: Net::SMTP::starttls was introduced in v3.01 (Re: [BUG] git-send-email broken: Can't locate object method "starttls")

: Eric Biggers <ebigge...@gmail.com> Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> --- Hi Eric, Eric Biggers wrote: > There seems to be a bug in 'git send-email' caused by this commit: > > commit 0ead000c3aca13a10ae51a3c74c866981e0d33b8 > Author: Dennis Kaars

Re: [PATCH v2] send-email: Net::SMTP::SSL is obsolete, use only when necessary

Hi, Dennis Kaarsemaker wrote: > Net::SMTP itself can do the necessary SSL and STARTTLS bits just fine > since version 1.28, and Net::SMTP::SSL is now deprecated. Since 1.28 > isn't that old yet, keep the old code in place and use it when > necessary. This broke git send-email for me. The error

Re: git push recurse.submodules behavior changed in 2.13

Hi John, John Shahid wrote: > It looks like the git push recurse-submodules behavior has changed. > Currently with 2.13 you cannot run "git push > --recurse-submodules=on-demand" if the parent repo is on a different > branch than the sub repos, e.g. parent repo is on "develop" and > sub-repo on

Re: What's cooking in git.git (May 2017, #06; Mon, 22)

Junio C Hamano wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> Junio C Hamano wrote: >>> * bw/forking-and-threading (2017-05-15) 14 commits [...] >>> The "run-command" API implementation has been made more robust >>> against dead-lo

Re: [PATCH v3 1/6] Fix build with core.autocrlf=true

, by using this cadence: > > git config core.autocrlf true > rm .git/index && git stash > make -j15 DEVELOPER=1 > > Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> > Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> >

Re: What's cooking in git.git (May 2017, #06; Mon, 22)

Hi, Junio C Hamano wrote: > * bw/forking-and-threading (2017-05-15) 14 commits > - usage.c: drop set_error_handle() > - run-command: restrict PATH search to executable files > - run-command: expose is_executable function > - run-command: block signals between fork and execve > -

Re: [PATCH 1/2] refs: Add for_each_worktree_ref for iterating over all worktree HEADs

(+cc: Duy, worktree expert) Hi Manish, Manish Goregaokar wrote: > Git prune will happily delete commits checked out in other worktrees. > This is probably not desired. Yikes. Thanks for working on it. > (Tabs have been converted to spaces in this email sadly, because GMail > garbles these.

Re: [PATCH] completion: add git stash push

on/git-completion.bash | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: git rebase regression: cannot pass a shell expression directly to --exec

Jeff King wrote: >>> On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote: One hack would be to look for BASH_FUNC_* in the environment and disable the optimization in that case. I think that would make your case Just Work. It doesn't help other oddball cases, like: [...] >>

Re: git rebase regression: cannot pass a shell expression directly to --exec

(+Brandon Williams, who may have more context for execvp-related things) Hi, Jeff King wrote: > On Mon, May 15, 2017 at 11:25:03PM -0400, Jeff King wrote: >> One hack would be to look for BASH_FUNC_* in the environment and disable >> the optimization in that case. I think that would make your

Re: [PATCH] fixup! log: add exhaustive tests for pattern style options & config

Hi, Johannes Schindelin wrote: > On Fri, 12 May 2017, Jonathan Nieder wrote: >> Would something like >> >> test PIPE_IN_FILENAME ' >> >"a|b" && >> test -f "a|b" >> ' >> >> work?

Re: [PATCH v7] fetch-pack: always allow fetching of literal SHA1s

ack.c | 40 ++-- > t/t5500-fetch-pack.sh | 35 +++++++ > 2 files changed, 73 insertions(+), 2 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> I think we've done enough golf on this one. Thanks for your patient work. Jonathan

Re: [PATCH v3] builtin/log: honor log.decorate

Junio C Hamano wrote: > "brian m. carlson" writes: >> The recent change that introduced autodecorating of refs accidentally >> broke the ability of users to set log.decorate = false to override it. >> When the git_log_config was traversed a second time with an

Re: [PATCH] config: complain about --local outside of a git repo

age_with_options(builtin_config_usage, > builtin_config_options); > } > > + if (use_local_config && nongit) > + die(_("--local only be used inside a git repository")); > + The output would be fatal: --local only be used inside a git repository Is that missing a "should" before "only"? With that change, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Re: [PATCH v2] builtin/log: honor log.decorate

Hi, brian m. carlson wrote: > Does anyone else have views on whether this is good thing to test for? I know you don't mean to be rude, but this comes across as a bit of a dismissive question. > On Fri, May 12, 2017 at 04:32:14PM -0700, Jonathan Nieder wrote: >> brian m. c

Re: [PATCH] fixup! log: add exhaustive tests for pattern style options & config

Johannes Schindelin wrote: > On Windows, `(1|2)` is not a valid file name, and therefore the tag > cannot be created as expected by the new test. > > So simply skip this test on Windows. > > Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> > --- Reviewed

Re: [PATCH v2] builtin/log: honor log.decorate

brian m. carlson wrote: > The recent change that introduced autodecorating of refs accidentally > broke the ability of users to set log.decorate = false to override it. Yikes. It sounds to me like we need a test to ensure we don't regress it again later. > When the git_log_config was traversed

Re: [PATCH v6] fetch-pack: always allow fetching of literal SHA1s

s changed, 68 insertions(+), 2 deletions(-) Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks for your patience.

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

(*newtail)->next; > > (making the function-to-abstract be merely an initialization one, > instead of one that does 2 things). That decreases the scope of the > function that Jonathan Nieder and Peff wanted, but it might be a > warranted reduction in scope. Yeah, that sounds nic

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin wrote: > On Fri, 12 May 2017, Junio C Hamano wrote: >> And this one is also important. I do not think we had to touch any >> code that handles .git/remotes/ or .git/branches when we extended >> the .git/config based configuration for remotes, simply because the >> old data

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

p_oids->map.cmpfn) { This feels like a layering violation. Could it be e.g. a static inline function oidset_is_initialized in oidset.h? > + add_refs_to_oidset(tip_oids, unmatched); > + add_refs_to_oidset(tip_oids, newlist); > + } > + return oidset

Re: [PATCH] C style: use standard style for "TRANSLATORS" comments

Hi, Ævar Arnfjörð Bjarmason wrote: > Change all the "TRANSLATORS: [...]" comments in the C code to use the > regular Git coding style, and amend the style guide so that the > example there uses that style. Hooray! [...] > --- a/Documentation/CodingGuidelines > +++

Re: [PATCH v4] fetch-pack: always allow fetching of literal SHA1s

Hi, Jonathan Tan wrote: > Thanks, peff. I've incorporated your suggestions - I don't feel very > strongly about this, but I guess it's worthwhile to avoid the quadratic > behavior if we can. > > Also incorporated Jonathan Nieder's suggestion about the placement of > the last line. The relevant

Re: [PATCH v4 0/2] perf: show that wildmatch() regressed for pathological cases in v2.0

+ > t/perf/perf-lib.sh | 19 +++ > 3 files changed, 59 insertions(+), 4 deletions(-) > create mode 100755 t/perf/p0100-globbing.sh Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [PATCH v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck

Hi, Jean-Noel Avila wrote: > Signed-off-by: Jean-Noel Avila <jn.av...@free.fr> > Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> Please remove my sign-off. I didn't write or carry this patch. If you want to acknowledge my contribution, you can use something like H

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

Jeff King wrote: > On Wed, May 10, 2017 at 10:00:44AM -0700, Jonathan Nieder wrote: >> Jeff King wrote: >>> [1] The reachability checks from upload-pack don't actually do much on >>> GitHub, because you can generally access the objects via the API or

Re: [PATCH v2 2/2] perf: add test showing exponential growth in path globbing

Hi, Ævar Arnfjörð Bjarmason wrote: > Add a test showing that ls-files times grow exponentially in the face > of some pathological globs, whereas refglobs via for-each-ref don't in > practice suffer from the same issue. Cool. [...] > --- /dev/null > +++ b/t/perf/p0100-globbing.sh > @@ -0,0

Re: [PATCH v2 1/2] perf: add function to setup a fresh test repo

Hi, Ævar Arnfjörð Bjarmason wrote: [...] > # call at least one of these to establish an appropriately-sized repository > +test_perf_fresh_repo () { > + repo="${1:-$TRASH_DIRECTORY}" > + "$MODERN_GIT" init -q "$repo" && > + cd "$repo" && > + test_perf_do_repo_symlink_config_ > +}

Re: [PATCH v3] fetch-pack: always allow fetching of literal SHA1s

ke it even clearer.) > --- a/t/t5500-fetch-pack.sh > +++ b/t/t5500-fetch-pack.sh > @@ -547,6 +547,41 @@ test_expect_success 'fetch-pack can fetch a raw sha1' ' Yay, thanks much for these. [...] > +test_expect_success 'fetch-pack can fetch a raw sha1 overlapping a named > ref' ' Ha, you read my mind. :) Except for the search-ref-list-for-oid function needing to be factored out, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

On Wed, May 10, 2017 at 12:48:37PM -0600, Martin Fick wrote: >> Ævar Arnfjörð Bjarmason wrote: >>> Just a side question, what are the people who use this >>> feature using it for? The only thing I can think of >>> myself is some out of band ref advertisement because >>> you've got squillions of

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

Hi, Ævar Arnfjörð Bjarmason wrote: > Just a side question, what are the people who use this feature using > it for? The only thing I can think of myself is some out of band ref > advertisement because you've got squillions of refs as a hack around > git's limitations in that area. That's one

Re: [PATCH v2] fetch-pack: always allow fetching of literal SHA1s

Hi, Jonathan Tan wrote: > fetch-pack, when fetching a literal SHA-1 from a server that is not > configured with uploadpack.allowtipsha1inwant (or similar), always > returns an error message of the form "Server does not allow request for > unadvertised object %s". However, it is sometimes the

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

Hi, Jeff King wrote: > Right, makes sense. I wondered if GitHub should be turning on > allowTipSHA1InWant, but it really doesn't make sense to. We _do_ hide > some internal refs[1], and they're things that users wouldn't want to > fetch. The problem for your case really is just on the client

Re: [ANNOUNCE] Git v2.12.3 and others

Junio C Hamano wrote: > Maintenance releases Git v2.4.12, v2.5.6, v2.6.7, v2.7.5, v2.8.5, > v2.9.4, v2.10.3, v2.11.2, and v2.12.3 have been tagged and are now > available at the usual places. > > These are primarily to fix a recently disclosed problem with "git > shell", which may allow a user

Re: [PATCH 3/3] protocol docs: explain receive-pack push options

Hi, Jonathan Tan wrote: > Support for push options in the receive-pack protocol (and all Git > components that speak it) have been added over a few commits, but not > fully documented (especially its interaction with signed pushes). Update > the protocol documentation to include the relevant

Re: [PATCH 2/3] receive-pack: verify push options in cert

Hi, Stefan Beller wrote: > On Fri, May 5, 2017 at 4:46 PM, Jonathan Tan wrote: >> This sets in stone the requirement that send-pack redundantly send its >> push options in 2 places, but I think that this is better than the >> alternatives. Sending push options only

Re: [PATCH 2/3] receive-pack: verify push options in cert

Hi, Jonathan Tan wrote: > In commit f6a4e61 ("push: accept push options", 2016-07-14), send-pack > was taught to include push options both within the signed cert (if the > push is a signed push) and outside the signed cert; however, > receive-pack ignores push options within the cert, only

Re: [PATCH 1/3] docs: correct receive.advertisePushOptions default

lity to its clients. If you don't want to advertise this > - capability, set this variable to false. > + When set to true, git-receive-pack will advertise the push options > + capability to its clients. Good catch. Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Possi

Re: [PATCH 0/3] Port git-add--interactive.perl:status_cmd to C

Ævar Arnfjörð Bjarmason wrote: > On Fri, May 5, 2017 at 8:43 PM, Daniel Ferreira wrote: >> This series introduces git-add-interactive--helper (or should it be >> called git-add--interactive--helper?) as a builtin capable of doing >> what the Perl script's status_cmd() would do.

Re: [PATCH v1 2/2] travis-ci: add job to run tests with GETTEXT_POISON

T_POISON is that it verifies that translatable strings are not affecting other functionality of Git. It's a valuable thing to test continuously. For what it's worth, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> Thanks.

Re: [PATCH 0/5] Start of a journey: drop NO_THE_INDEX_COMPATIBILITY_MACROS

Hi, Junio C Hamano wrote: > Duy Nguyen writes: >> I attempted the same thing once or twice in the past, had the same >> impression and dropped it. But I think it's good to get rid of cache_* >> macros, at least outside builtin/ directory. > > One thing that needs to be kept

Re: [PATCH 00/10] RFC Partial Clone and Fetch

ething like Martin Fick's "git exproll" ( http://public-inbox.org/git/1375756727-1275-1-git-send-email-artag...@gmail.com/) into "git gc --auto" to more aggressively keep the number of packs down. > On 5/3/2017 2:27 PM, Jonathan Nieder wrote: >> If we were starting

Re: [PATCH 00/10] RFC Partial Clone and Fetch

Hi, Jonathan Tan wrote: > The binary search to lookup a packfile offset from a .idx file > (which involves disk reads) would take longer for all lookups (not > just lookups for missing blobs) - I think I prefer keeping the lists > separate, to avoid pessimizing the (likely) usual case where the

Re: [PATCH] config.mak.uname: set NO_REGEX=NeedsStartEnd on AIX

Hi, Stefan Beller wrote: > On Wed, May 3, 2017 at 12:47 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: >> Is there e.g. a build farm where we can check for this kind of thing >> more systematically on supported platforms? > > There is the OpenSuse build farm that pr

<    5   6   7   8   9   10   11   12   13   14   >