Re: [PATCH 0/4]

Stefan Beller writes: > A couple days before the 2.19 release we had a bug report about > broken submodules[1] and reverted[2] the commits leading up to them. > > The behavior of said bug fixed itself by taking a different approach[3], > specifically by a weaker enforcement of having

Re: [PATCH 0/4] mingw: prevent external PERL5LIB from interfering

Hi Junio, On Wed, 31 Oct 2018, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > An alternative approach which was rejected at the time (because it > > interfered with the then-ongoing work to compile Git for Windows using > > MS Visual C++) would patch the

Re: [PATCH 0/4] mingw: prevent external PERL5LIB from interfering

"Johannes Schindelin via GitGitGadget" writes: > An alternative approach which was rejected at the time (because it > interfered with the then-ongoing work to compile Git for Windows using MS > Visual C++) would patch the make_environment_block() function to skip the > specified environment

Re: [PATCH 0/4] index-pack: optionally turn off SHA-1 collision checking

Geert Jansen writes: > Maybe a better option would be to check for the non-existence of the [00-ff] > directories under .git/objects. Please do not do this; I expect many people do this before they leave work, just like I do: $ git repack -a -d -f --window=$largs --depth=$small

Re: [PATCH 0/4] index-pack: optionally turn off SHA-1 collision checking

On Sun, Oct 28, 2018 at 10:50:19PM +, Ævar Arnfjörð Bjarmason wrote: > I left the door open for that in the new config option 4/4 implements, > but I suspect for Geert's purposes this is something he'd prefer to > turn off in git on clone entirely, i.e. because it may be running on > some

Re: [PATCH 0/4] Bloom filter experiment

Ævar Arnfjörð Bjarmason writes: >> This is all to say: having a maximum size is good. 512 is big enough >> to cover _most_ commits, but not so big that we may store _really_ big >> filters. > > Makes sense. 512 is good enough to hardcode initially, but I couldn't > tell from briefly skimming the

Re: [PATCH 0/4] Bloom filter experiment

> | Implementation | Queries | Maybe | FP # | FP %  | > ||-|---|--|---| > | Szeder | 66095   | 1142  | 256  | 0.38% | > | Jonathan   | 66459   | 107   | 89   | 0.16% | > | Stolee | 53025   | 492   | 479  | 0.90% | > > (Note that we must have

Re: [PATCH 0/4] Bloom filter experiment

On 10/16/2018 8:57 AM, Ævar Arnfjörð Bjarmason wrote: On Tue, Oct 16 2018, Derrick Stolee wrote: On 10/16/2018 12:45 AM, Junio C Hamano wrote: Derrick Stolee writes: 2. The filters are sized according to the number of changes in each commit, with a minimum of one 64-bit word. ... 6. When

Re: [PATCH 0/4] Bloom filter experiment

On Tue, Oct 16 2018, Derrick Stolee wrote: > On 10/16/2018 12:45 AM, Junio C Hamano wrote: >> Derrick Stolee writes: >> >>> 2. The filters are sized according to the number of changes in each >>> commit, with a minimum of one 64-bit word. >>> ... >>> 6. When we compute the Bloom filters, we

Re: [PATCH 0/4] Bloom filter experiment

On 10/16/2018 12:45 AM, Junio C Hamano wrote: Derrick Stolee writes: 2. The filters are sized according to the number of changes in each commit, with a minimum of one 64-bit word. ... 6. When we compute the Bloom filters, we don't store a filter for commits whose first-parent diff has more

Re: [PATCH 0/4] Bloom filter experiment

Derrick Stolee writes: > 2. The filters are sized according to the number of changes in each > commit, with a minimum of one 64-bit word. > ... > 6. When we compute the Bloom filters, we don't store a filter for > commits whose first-parent diff has more than 512 paths. Just being curious but

Re: [PATCH 0/4] Bloom filter experiment

On 10/9/2018 3:34 PM, SZEDER Gábor wrote: To keep the ball rolling, here is my proof of concept in a somewhat cleaned-up form, with still plenty of rough edges. Peff, Szeder, and Jonathan, Thanks for giving me the kick in the pants to finally write a proof of concept for my personal take on

Re: [PATCH 0/4] Bloom filter experiment

On 10/9/2018 3:34 PM, SZEDER Gábor wrote: To keep the ball rolling, here is my proof of concept in a somewhat cleaned-up form, with still plenty of rough edges. You can play around with it like this: $ GIT_USE_POC_BLOOM_FILTER=$((8*1024*1024*8)) git commit-graph write Computing commit

Re: [PATCH 0/4] un-breaking pack-objects with bitmaps

Jeff King writes: >> Either is fine. I am not moving 'next' beyond what is necessary for >> this release cycle during the pre-release freeze period, and because >> I thought that Peff was in favor of squashing in the changes to the >> original when the next cycle starts, I haven't bothered to

Re: [PATCH 0/4] un-breaking pack-objects with bitmaps

On Mon, Sep 10, 2018 at 09:53:56AM -0700, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > I'm just reverting jk/pack-delta-reuse-with-bitmap out of next when > > building my own package of git, but I think this really should be fixed > > in that branch, either by merging the fix

Re: [PATCH 0/4] un-breaking pack-objects with bitmaps

Ævar Arnfjörð Bjarmason writes: > I'm just reverting jk/pack-delta-reuse-with-bitmap out of next when > building my own package of git, but I think this really should be fixed > in that branch, either by merging the fix down or reverting the original > series out of next, I think just merging

Re: [PATCH 0/4] un-breaking pack-objects with bitmaps

On Sat, Sep 01 2018, Jeff King wrote: > On Fri, Aug 31, 2018 at 06:55:58PM -0400, Jeff King wrote: > >> On Fri, Aug 31, 2018 at 05:23:17PM +0200, Ævar Arnfjörð Bjarmason wrote: >> >> > On Tue, Aug 21 2018, Jeff King wrote: >> > >> > > +int bitmap_has_sha1_in_uninteresting(struct bitmap_index

Re: [PATCH 0/4] un-breaking pack-objects with bitmaps

On Tue, Sep 04, 2018 at 12:30:14PM -0700, Stefan Beller wrote: > > [1/4]: bitmap_has_sha1_in_uninteresting(): drop BUG check > > > > The actual fix. This should get merged to next ASAP (or the original > > topic just reverted). > > > > [2/4]: t5310: test delta reuse with bitmaps > > >

Re: [PATCH 0/4] un-breaking pack-objects with bitmaps

> [1/4]: bitmap_has_sha1_in_uninteresting(): drop BUG check > > The actual fix. This should get merged to next ASAP (or the original > topic just reverted). > > [2/4]: t5310: test delta reuse with bitmaps > > I did this separately to give us flexibility to squash or merge >

Re: [PATCH 0/4] tests: make more use of 'test_must_be_empty'

Note that you can also trivially convert a lot more instances of empty checking to the "right" way: 'test_line_count = 0' $ grep -Ir 'test_line_count = 0' t | wc -l 76 I think it would be nice to clean these up as well.

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Hi Peff, On Fri, 10 Aug 2018, Jeff King wrote: > On Fri, Aug 10, 2018 at 06:43:07PM +0200, Johannes Schindelin wrote: > > > So unless you are willing to ignore, to willfully keep this breakage, > > I would suggest not to introduce the ugliness of an overridden > > upload-pack for the sole

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

On Fri, Aug 10, 2018 at 11:34:59AM -0700, Junio C Hamano wrote: > Johannes Sixt writes: > > > As this buglet looks like a recurring theme, and a proper fix is > > preferable over repeated work-arounds. To me it looks like we need > > some sort of locking on Windows. Unless your friends at

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Jeff King writes: > I have tried to help with the actual problem, by identifying the root > cause (that the trace code's strategy is not fundamentally broken, but > that it relies on O_APPEND whose guarantees are obviously not portable > to Windows) and exploring possible solutions there

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Johannes Sixt writes: > As this buglet looks like a recurring theme, and a proper fix is > preferable over repeated work-arounds. To me it looks like we need > some sort of locking on Windows. Unless your friends at Microsoft have > an ace in their sleeves that lets us have atomic O_APPEND the

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

On Fri, Aug 10, 2018 at 06:43:07PM +0200, Johannes Schindelin wrote: > > > Correct. But I am more worried about the "mixed/overwriting" > > > breakage, if there is one; it means we may need to be prepared for > > > systems that lack O_APPEND that works correctly. I initially just > > > assumed

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Am 10.08.2018 um 18:51 schrieb Jeff Hostetler: On 8/10/2018 12:15 PM, Johannes Sixt wrote: Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget: I reported a couple of times that t5552 is not passing reliably. It has now reached next, and will no doubt infect master soon.

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

On 8/10/2018 12:51 PM, Jeff Hostetler wrote: On 8/10/2018 12:15 PM, Johannes Sixt wrote: Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget: I reported a couple of times that t5552 is not passing reliably. It has now reached next, and will no doubt infect master soon.

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

On 8/10/2018 12:15 PM, Johannes Sixt wrote: Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget: I reported a couple of times that t5552 is not passing reliably. It has now reached next, and will no doubt infect master soon. Turns out that it is not a Windows-specific

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Hi, On Fri, 10 Aug 2018, Jeff King wrote: > On Thu, Aug 09, 2018 at 01:49:52PM -0700, Junio C Hamano wrote: > > > Jeff King writes: > > > > > Are you sure that it's not well-defined? We open the path with O_APPEND, > > > which means every write() will be atomically positioned at the end of >

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget: I reported a couple of times that t5552 is not passing reliably. It has now reached next, and will no doubt infect master soon. Turns out that it is not a Windows-specific issue, even if it occurs a lot more often on Windows

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Jeff King writes: > Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets > us pursue any fix for interleaved trace output on Windows without the > pressure of an impending flaky test. > > My gut says that looking into making O_APPEND work there is going to be > the nicest

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Jeff King writes: > Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets > us pursue any fix for interleaved trace output on Windows without the > pressure of an impending flaky test. > > My gut says that looking into making O_APPEND work there is going to be > the nicest

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

On Thu, Aug 09, 2018 at 01:49:52PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Are you sure that it's not well-defined? We open the path with O_APPEND, > > which means every write() will be atomically positioned at the end of > > file. So we would never lose or overwrite data. > > >

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

On Thu, Aug 09, 2018 at 02:08:56PM -0700, Junio C Hamano wrote: > > Correct. But I am more worried about the "mixed/overwriting" > > breakage, if there is one; it means we may need to be prepared for > > systems that lack O_APPEND that works correctly. I initially just > > assumed that it was

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Junio C Hamano writes: > Jeff King writes: > >> Are you sure that it's not well-defined? We open the path with O_APPEND, >> which means every write() will be atomically positioned at the end of >> file. So we would never lose or overwrite data. >> >> We do our own buffering in a strbuf, writing

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

Jeff King writes: > Are you sure that it's not well-defined? We open the path with O_APPEND, > which means every write() will be atomically positioned at the end of > file. So we would never lose or overwrite data. > > We do our own buffering in a strbuf, writing the result out in a single >

Re: [PATCH 0/4] t5552: fix flakiness by introducing proper locking for GIT_TRACE

On Thu, Aug 09, 2018 at 10:35:24AM -0700, Johannes Schindelin via GitGitGadget wrote: > The culprit is that two processes try simultaneously to write to the same > file specified via GIT_TRACE_PACKET, and it is not well defined how that > should work, even on Linux. Are you sure that it's not

Re: [PATCH 0/4] line-log: be more careful when adjusting multiple line ranges

On Sat, Aug 4, 2018 at 6:18 PM Johannes Schindelin via GitGitGadget wrote: > Now, I am fairly certain that the changes are correct, but given my track > record with off-by-one bugs (and once even an off-by-two bug), I would > really appreciate some thorough review of this code, in particular the

Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file()

Johannes Schindelin writes: > Hi Olga, > > On Fri, 13 Jul 2018, Оля Тележная wrote: > >> 2018-07-09 11:27 GMT+03:00 Оля Тележная : >> > Hello everyone, >> > This is my new attempt to start using oid_object_info_extended() in >> > ref-filter. You could look at previous one [1] [2] but it is not

Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file()

Hi Olga, On Fri, 13 Jul 2018, Оля Тележная wrote: > 2018-07-09 11:27 GMT+03:00 Оля Тележная : > > Hello everyone, > > This is my new attempt to start using oid_object_info_extended() in > > ref-filter. You could look at previous one [1] [2] but it is not > > necessary. > > > > The goal (still)

Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file()

2018-07-09 11:27 GMT+03:00 Оля Тележная : > Hello everyone, > This is my new attempt to start using oid_object_info_extended() in > ref-filter. You could look at previous one [1] [2] but it is not > necessary. > > The goal (still) is to improve performance by avoiding calling expensive > functions

Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file()

Hi Olga, On Mon, 9 Jul 2018, Оля Тележная wrote: > [2] > https://public-inbox.org/git/010201637254c969-a346030e-0b75-41ad-8ef3-2ac7e04ba4fb-000...@eu-west-1.amazonses.com/ This type of Message-Id makes me think that you used SubmitGit to send this patch series. The main problem I see here is

Re: [PATCH 0/4] Use oid_object_info() instead of read_object_file()

Оля Тележная writes: > Hello everyone, > This is my new attempt to start using oid_object_info_extended() in > ref-filter. You could look at previous one [1] [2] but it is not > necessary. Yup, it sounds like a sensible thing to do to try asking object-info helper instead of reading the whole

Re: [PATCH 0/4] fsck: doc fixes & fetch.fsck.* implementation

Ævar Arnfjörð Bjarmason writes: > On Thu, May 24, 2018 at 9:02 PM, Jeff King wrote: >> On Thu, May 24, 2018 at 07:04:04PM +0200, Ævar Arnfjörð Bjarmason wrote: >> >>> That doesn't work, because that's for the server-side, but I need the >>> fetch.fsck.* that

Re: [PATCH 0/4] a few mark_parents_uninteresting cleanups

On 5/11/2018 2:00 PM, Jeff King wrote: This is a follow-up to the discussion from February: https://public-inbox.org/git/1519522496-73090-1-git-send-email-dsto...@microsoft.com/ There I theorized that some of these extra has_object_file() checks were unnecessary. After poking around a bit,

Re: [PATCH 0/4] doc: cleaning up instances of \--

On Wed, Apr 18, 2018 at 01:24:55PM +0900, Junio C Hamano wrote: > Martin Ågren writes: > > > This is a patch series to convert \-- to -- in our documentation. The > > first patch is a reiteration of 1c262bb7b2 (doc: convert \--option to > > --option, 2015-05-13) to fix

Re: [PATCH 0/4] subtree: move out of contrib

On Tue, May 01 2018, Johannes Schindelin wrote: > Hi Ævar, > > On Mon, 30 Apr 2018, Ævar Arnfjörð Bjarmason wrote: > >> I think at this point git-subtree is widely used enough to move out of >> contrib/, maybe others disagree, but patches are always better for >> discussion that patch-less ML

Re: [PATCH 0/4] subtree: move out of contrib

Hi Ævar, On Mon, 30 Apr 2018, Ævar Arnfjörð Bjarmason wrote: > I think at this point git-subtree is widely used enough to move out of > contrib/, maybe others disagree, but patches are always better for > discussion that patch-less ML posts. Sure, it is used widely enough. However, it flies in

Re: [PATCH 0/4] subtree: move out of contrib

On Mon, Apr 30, 2018 at 11:50 AM, Ævar Arnfjörð Bjarmason wrote: > I think at this point git-subtree is widely used enough to move out of > contrib/, maybe others disagree, but patches are always better for > discussion that patch-less ML posts. After narrow/partial clone

Re: [PATCH 0/4] subtree: move out of contrib

On Mon, Apr 30, 2018 at 6:21 PM, Ævar Arnfjörð Bjarmason wrote: > Pretty clear it's garbage data, unless we're to believe that the > relative interest of submodules in the US, Germany and Sweden is 51, 64 > & 84, but 75, 100 and 0 for subtree. Oh yeah, Swedish people hate

Re: [PATCH 0/4] subtree: move out of contrib

On Mon, Apr 30 2018, Avery Pennarun wrote: > On Mon, Apr 30, 2018 at 5:38 PM, Stefan Beller wrote: > There's one exception, which is doing a one-time permanent merge of > two projects into one. That's a nice feature, but is probably used > extremely rarely. FWIW this is

Re: [PATCH 0/4] subtree: move out of contrib

On Mon, Apr 30, 2018 at 2:53 PM, Avery Pennarun wrote: > For the best of both worlds, I've often thought that a good balance > would be to use the same data structure that submodule uses, but to > store all the code in a single git repo under different refs, which we > might

Re: [PATCH 0/4] subtree: move out of contrib

On Mon, Apr 30, 2018 at 5:38 PM, Stefan Beller wrote: > On Mon, Apr 30, 2018 at 1:45 PM, Avery Pennarun wrote: > No objections from me either. > > Submodules seem to serve a slightly different purpose, though? I think the purpose is actually the same -

Re: [PATCH 0/4] subtree: move out of contrib

On Mon, Apr 30, 2018 at 1:45 PM, Avery Pennarun wrote: > On Mon, Apr 30, 2018 at 5:50 AM, Ævar Arnfjörð Bjarmason > wrote: >> I think at this point git-subtree is widely used enough to move out of >> contrib/, maybe others disagree, but patches are always

Re: [PATCH 0/4] subtree: move out of contrib

On Mon, Apr 30, 2018 at 5:50 AM, Ævar Arnfjörð Bjarmason wrote: > I think at this point git-subtree is widely used enough to move out of > contrib/, maybe others disagree, but patches are always better for > discussion that patch-less ML posts. I really was hoping git-subtree

Re: [PATCH 0/4] subtree: move out of contrib

From: "Ævar Arnfjörð Bjarmason" I think at this point git-subtree is widely used enough to move out of contrib/, maybe others disagree, but patches are always better for discussion that patch-less ML posts. Assuming this lands in Git, then there will also need to be a

Re: [PATCH 0/4] doc: cleaning up instances of \--

On Tue, Apr 17, 2018 at 09:15:25PM +0200, Martin Ågren wrote: > This is a patch series to convert \-- to -- in our documentation. The > first patch is a reiteration of 1c262bb7b2 (doc: convert \--option to > --option, 2015-05-13) to fix some instances that have appeared since. > The other three

Re: [PATCH 0/4] doc: cleaning up instances of \--

Martin Ågren writes: > This is a patch series to convert \-- to -- in our documentation. The > first patch is a reiteration of 1c262bb7b2 (doc: convert \--option to > --option, 2015-05-13) to fix some instances that have appeared since. > The other three patches deal with

Re: [PATCH 0/4] Convert some stash functionality to a builtin

On 03/24, Joel Teichroeb wrote: > I've been working on converting all of git stash to be a > builtin, however it's hard to get it all working at once with > limited time, so I've moved around half of it to a new > stash--helper builtin and called these functions from the shell > script. Once this

Re: [PATCH 0/4] Speed up git tag --contains

On Mon, Mar 12, 2018 at 09:45:27AM -0400, Derrick Stolee wrote: > > diff --git a/builtin/branch.c b/builtin/branch.c > > index 8dcc2ed058..4d674e86d5 100644 > > --- a/builtin/branch.c > > +++ b/builtin/branch.c > > @@ -404,6 +404,7 @@ static void print_ref_list(struct ref_filter *filter, > >

Re: [PATCH 0/4] Speed up git tag --contains

On 3/3/2018 12:15 AM, Jeff King wrote: On Fri, Jan 12, 2018 at 10:56:00AM -0800, csilvers wrote: This is a resubmission of Jeff King's patch series to speed up git tag --contains with some changes. It's been cooking for a while as: Replying to this 6-year-old thread: Is there any chance this

Re: [PATCH 0/4] Speed up git tag --contains

} I had a few proposals over the years, but I won't even bother to dig } them up, because there's quite recent and promising work in this } area from Derrick Stolee: It sounds like the best thing to do is to wait for this, then. We managed to convert a bunch of our branches to tags, so our

Re: [PATCH 0/4] Teach `--default` to `git-config(1)`

On Mon, Mar 05, 2018 at 06:17:25PM -0800, Taylor Blau wrote: > Attached is a patch series to introduce `--default` and `--color` to the > `git-config(1)` builtin with the aim of introducing a consistent interface to > replace `--get-color`. This series draws significant inspiration from Soukaina

Re: [PATCH 0/4] Speed up git tag --contains

On Fri, Jan 12, 2018 at 10:56:00AM -0800, csilvers wrote: > > This is a resubmission of Jeff King's patch series to speed up git tag > > --contains with some changes. It's been cooking for a while as: > > Replying to this 6-year-old thread: > > Is there any chance this could be resurrected? We

Re: [PATCH 0/4] Delete ignore_env member in struct repository

On Tue, Feb 27, 2018 at 3:46 AM, Stefan Beller wrote: > What is the plan from here on? > Should I build further series on top of yours? The next series will > focus on the pack side of things (pack.h, packfile.{c,h}) > > So maybe we'll have Junio merge down my series (and

Re: [PATCH 0/4] Delete ignore_env member in struct repository

On Mon, Feb 26, 2018 at 2:30 AM, Nguyễn Thái Ngọc Duy wrote: > It turns out I don't need my other series [1] in order to delete this > field. This series moves getenv() calls from > repo_set_gitdir()/repo_setup_env() and prepare_alt_odb() back in > environment.c where they

Re: [PATCH 0/4] Delete ignore_env member in struct repository

Nguyễn Thái Ngọc Duy writes: > This series is built on top of Stefan's object-store-part1, v4. I > could rebase it on 'master' too, but then Junio may need to resolve > some conflicts. As a follow-up fix for combined "move things to the_repo as much as possible" efforts I

Re: [PATCH 0/4] Correct offsets of hunks when one is skipped

On 13/02/18 23:56, brian m. carlson wrote: > On Tue, Feb 13, 2018 at 10:44:04AM +, Phillip Wood wrote: >> From: Phillip Wood >> >> While working on a patch series to stage selected lines from a hunk >> without having to edit it I got worried that subsequent patches

Re: [PATCH 0/4] Correct offsets of hunks when one is skipped

On Tue, Feb 13, 2018 at 10:44:04AM +, Phillip Wood wrote: > From: Phillip Wood > > While working on a patch series to stage selected lines from a hunk > without having to edit it I got worried that subsequent patches would > be applied in the wrong place which

Re: [PATCH 0/4] Speed up git tag --contains

> This is a resubmission of Jeff King's patch series to speed up git tag > --contains with some changes. It's been cooking for a while as: Replying to this 6-year-old thread: Is there any chance this could be resurrected? We are using phabricator, which uses `git branch --contains` as part of

Re: [PATCH 0/4] "Fast-"track Git GUI changes

Hi, On Tue, 9 Jan 2018, Junio C Hamano wrote: > Junio C Hamano writes: > > > Johannes Schindelin writes: > > > >> As it seems to be impossible to get the attention of the Git GUI > >> maintainer these "days" (I have opened Pull Requests on

Re: [PATCH 0/4] "Fast-"track Git GUI changes

Junio C Hamano writes: > Johannes Schindelin writes: > >> As it seems to be impossible to get the attention of the Git GUI >> maintainer these "days" (I have opened Pull Requests on October 16th >> 2016 that have not even been looked at), let's

Re: [PATCH 0/4] "Fast-"track Git GUI changes

Johannes Schindelin writes: > As it seems to be impossible to get the attention of the Git GUI > maintainer these "days" (I have opened Pull Requests on October 16th > 2016 that have not even been looked at), let's just side-step that > contribution path which seems

Re: [PATCH 0/4] Add --no-ahead-behind to status

On Wed, Dec 20, 2017 at 02:42:41PM +, Jeff Hostetler wrote: > From: Jeff Hostetler > > This patch series adds a "--no-ahead-behind" option to status > to request that it avoid a possibly expensive ahead/behind > computation for the current branch. Instead, it just

Re: [PATCH 0/4] Fix issues with rename detection limits

On Fri, Nov 10, 2017 at 10:13 AM, Elijah Newren wrote: > In a repo with around 60k files with deep directory hierarchies (due to > Elijah Newren (4): > sequencer: Warn when internal merge may be suboptimal due to > renameLimit > Remove silent clamp of renameLimit >

Re: [PATCH 0/4] WIP: git-remote-media wiki namespace support

On 2017-10-30 11:40:06, Matthieu Moy wrote: > Antoine Beaupré writes: > >> Obviously, doing unit tests against a full MediaWiki instance isn't >> exactly trivial. > > Not trivial, but doable: there is all the infrastructure to do so in t/: > install-wiki.sh to automatically

Re: [PATCH 0/4] WIP: git-remote-media wiki namespace support

Antoine Beaupré writes: > Obviously, doing unit tests against a full MediaWiki instance isn't > exactly trivial. Not trivial, but doable: there is all the infrastructure to do so in t/: install-wiki.sh to automatically install Mediawiki, and then a testsuite that interacts

Re: [PATCH 0/4] (x)diff cleanup: remove duplicate code

On Tue, Oct 24, 2017 at 11:59 AM, Stefan Beller wrote: > Junio wrote: > >> * I was hoping that the next_byte() and string_hash() thing, once >>they are cleaned up, will eventually be shared with the xdiff/ >>code at the lower layer, which needs to do pretty much the

Re: [PATCH 0/4] fsmonitor fixes

Hi Alex, On Thu, 19 Oct 2017, Alex Vandiver wrote: > A few fixes found from playing around with the fsmonitor branch in > next. Thank you for having a look, and even better: for sending a couple of improvements on top of Ben's & my work. I sent a couple of suggestions and hope you will find

Re: [PATCH 0/4] pre-merge hook

Michael J Gruber writes: > This series revives an old suggestion of mine to make merge honor > pre-commit hook or a separate pre-merge hook This seems to have become an abandoned loose end, so I'll drop the topic from my tree for now; revival of the discussion is _not_

Re: [PATCH 0/4] pre-merge hook

On Sun, Oct 1, 2017 at 10:54 PM, Junio C Hamano wrote: > Michael J Gruber writes: > >> Now that f8b863598c ("builtin/merge: honor commit-msg hook for merges", >> 2017-09-07) has landed, merge is getting closer to behaving like commit, >> which is important

Re: [PATCH 0/4] pre-merge hook

Michael J Gruber writes: > Now that f8b863598c ("builtin/merge: honor commit-msg hook for merges", > 2017-09-07) has landed, merge is getting closer to behaving like commit, > which is important because both are used to complete merges (automatic > vs. non-automatic). Just a

Re: [PATCH 0/4] Fixes from the per-repository object store series

Jonathan Nieder writes: > This is a continuation of the series at [1]. That was part 1 --- > you can think of this as part 0, since it contains the simplest and > least controversial part of the series --- each patch in this series > is a bugfix in its own right. > > Patch 1

Re: [PATCH 0/4] Test name-rev with small stack

On Fri, Sep 08, 2017 at 02:33:35PM +0200, Michael J Gruber wrote: > Looking at it more closely, the solution in cbc60b6720 ("git tag > --contains: avoid stack overflow", 2014-04-24) seems to be a bit "ad > hoc" to me: > > First of all, there is more than "tag --contains" that may exceed the >

Re: [PATCH 0/4] Test name-rev with small stack

Jeff King venit, vidit, dixit 07.09.2017 16:54: > On Thu, Sep 07, 2017 at 04:02:19PM +0200, Michael J Gruber wrote: > >> name-rev segfaults for me in emacs.git with the typical 8102 stack size. >> The reason is the recursive walk that name-rev uses. >> >> This series adds a test to mark this as

Re: [PATCH 0/4] Test name-rev with small stack

On Thu, Sep 07, 2017 at 04:02:19PM +0200, Michael J Gruber wrote: > name-rev segfaults for me in emacs.git with the typical 8102 stack size. > The reason is the recursive walk that name-rev uses. > > This series adds a test to mark this as known failure, after some > clean-ups. These all look

Re: [PATCH 0/4] vcs-svn: remove repo_tree library

On Tue, Aug 22, 2017 at 4:37 PM, Jonathan Nieder wrote: > Hi, > > Stefan noticed that repo_init from vcs-svn/repo_tree.h conflicts with > repository.h[1]. Earlier brian m. carlson noticed the same thing[2]. > > Originally repo_tree.h was used to manage an in-memory

Re: [PATCH 0/4] dropping support for older curl

Hi Paolo, On Thu, 10 Aug 2017, Paolo Ciarrocchi wrote: > Il 10 ago 2017 11:39 AM, "Johannes Schindelin" > ha scritto: > > > > Footnote *1*: It is no secret that I find our patch submission less than > inviting. Granted, *I* use it. *I* did not have problems

Re: [PATCH 0/4] dropping support for older curl

On Thu, Aug 10, 2017 at 07:09:02PM -0400, Jeff King wrote: > The first is "should we eventually drop support for antiquated versions > of dependencies?". And the argument in favor is the one I was making > here: besides lowering maintenance cost, it is more honest to our users > about what to

Re: [PATCH 0/4] dropping support for older curl

On 11/08/17 01:23, Jeff King wrote: On Fri, Aug 11, 2017 at 01:17:51AM +0200, Tom G. Christensen wrote: OK, thanks for double-checking. I'm still puzzled why your build succeeds and mine does not. I know what's going on now and it's so simple. Red Hats version of curl 7.15.5 includes a

Re: [PATCH 0/4] dropping support for older curl

On Fri, Aug 11, 2017 at 01:17:51AM +0200, Tom G. Christensen wrote: > > OK, thanks for double-checking. I'm still puzzled why your build > > succeeds and mine does not. > > I know what's going on now and it's so simple. > Red Hats version of curl 7.15.5 includes a number of patches including one

Re: [PATCH 0/4] dropping support for older curl

On 11/08/17 00:54, Jeff King wrote: On Fri, Aug 11, 2017 at 12:23:42AM +0200, Tom G. Christensen wrote: Er, sorry if I'm being dense, but how? Are you suggesting that by removing the callsite of get_curl_allowed_protocols(), the compiler might elide the now-dead code completely? I could

Re: [PATCH 0/4] dropping support for older curl

On Thu, Aug 10, 2017 at 03:17:06PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Thu, Aug 10, 2017 at 11:36:41AM +0200, Johannes Schindelin wrote: > > > >> Hopefully I had better luck expressing my concerns this time? > > > > I understand your argument much better

Re: [PATCH 0/4] dropping support for older curl

On Fri, Aug 11, 2017 at 12:23:42AM +0200, Tom G. Christensen wrote: > > > I just built a pristine 2.14.0 on CentOS 5 with curl 7.15.5. No problems > > > at > > > all neither with building nor with running the testsuite. > > > > As you can see, this does not compile for me. What's going on? > >

Re: [PATCH 0/4] dropping support for older curl

On 10/08/17 23:32, Jeff King wrote: On Thu, Aug 10, 2017 at 10:33:18PM +0200, Tom G. Christensen wrote: You've totally ignored the argument I made back then[1], and which I reiterated in this thread. So I'll say it one more time: the more compelling reason is not the #ifdefs, but the fact that

Re: [PATCH 0/4] dropping support for older curl

Jeff King writes: > On Thu, Aug 10, 2017 at 11:36:41AM +0200, Johannes Schindelin wrote: > >> Hopefully I had better luck expressing my concerns this time? > > I understand your argument much better now. I'm still not sure I agree. > > -Peff I do not think "there are a dozen

Re: [PATCH 0/4] dropping support for older curl

On Thu, Aug 10, 2017 at 11:36:41AM +0200, Johannes Schindelin wrote: > Hopefully I had better luck expressing my concerns this time? I understand your argument much better now. I'm still not sure I agree. -Peff

Re: [PATCH 0/4] dropping support for older curl

On Thu, Aug 10, 2017 at 10:33:18PM +0200, Tom G. Christensen wrote: > > You've totally ignored the argument I made back then[1], and which I > > reiterated in this thread. So I'll say it one more time: the more > > compelling reason is not the #ifdefs, but the fact that the older > > versions are

Re: [PATCH 0/4] dropping support for older curl

On 09/08/17 23:47, Jeff King wrote: On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote: I mean, if we even go out of our way to support the completely outdated and obsolete .git/branches/ for what is likely a single user, it may not be the worst to keep those couple of #ifdef

Re: [PATCH 0/4] dropping support for older curl

[I am resending this since the original does not seem to have made it to the list, at least I cannot find it in any archives] On 09/08/17 23:47, Jeff King wrote: On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote: I mean, if we even go out of our way to support the completely

  1   2   3   4   >