Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-25 Thread Stefan Beller
On Wed, Oct 24, 2018 at 6:59 PM SZEDER Gábor wrote: > > On Mon, Oct 22, 2018 at 11:54:06AM -0700, Stefan Beller wrote: > > > For the sake of a good history, I would think running 'make coccicheck' > > and applying the resulting patches would be best as part of the (dirty) > > merge of any topic

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-24 Thread Jeff King
On Mon, Oct 22, 2018 at 07:39:35PM +0200, SZEDER Gábor wrote: > I don't really like how this or the previous RFC patch series deal > with semantic patches (or how some past patch series dealt with them, > for that matter), for various reasons: > [..] I am a little late to this thread, but it

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-24 Thread SZEDER Gábor
On Mon, Oct 22, 2018 at 11:54:06AM -0700, Stefan Beller wrote: > For the sake of a good history, I would think running 'make coccicheck' > and applying the resulting patches would be best as part of the (dirty) > merge of any topic that proposes new semantic patches, but that would > add load to

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-23 Thread Junio C Hamano
Stefan Beller writes: >> Anyway, even though "make coccicheck" does not run in subsecond, >> I've updated my machinery to rebuild the integration branches so >> that I can optionally queue generated coccicheck patches, and what I >> pushed out tonight has one at the tip of 'pu' and also another

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-23 Thread Stefan Beller
On Tue, Oct 23, 2018 at 2:38 AM Junio C Hamano wrote: > > Junio C Hamano writes: > > > I actually think this round does a far nicer job playing well with > > other topics than any earlier series. The pain you are observing I > > think come primarily from my not making the best use of these > >

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-23 Thread Junio C Hamano
Carlo Arenas writes: > On Tue, Oct 23, 2018 at 2:40 AM Junio C Hamano wrote: >> >> The tip of 'pu' has trouble with -Wunused on Apple around the >> delta-islands series. > > FWIW the "problem" is actually with -Wunused-function and is AFAIK not > related to the semantic changes or Apple (AKA

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-23 Thread Carlo Arenas
On Tue, Oct 23, 2018 at 2:40 AM Junio C Hamano wrote: > > The tip of 'pu' has trouble with -Wunused on Apple around the > delta-islands series. FWIW the "problem" is actually with -Wunused-function and is AFAIK not related to the semantic changes or Apple (AKA macOS) Indeed, I saw this issue

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-23 Thread Junio C Hamano
Junio C Hamano writes: > I actually think this round does a far nicer job playing well with > other topics than any earlier series. The pain you are observing I > think come primarily from my not making the best use of these > patches. > > Steppng back a bit, I'd imagine in an ideal world where

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-22 Thread Junio C Hamano
Stefan Beller writes: > Am I overestimating or misunderstanding rerere here? Yes. > Would it be realistic for next and master branch instead of pu? > > I'd be wary for the master branch, as we may not want to rely on > spatch without review. (It can produce funny white space issues, > but

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-22 Thread Stefan Beller
> Stepping back a bit, I'd imagine in an ideal world where "make > coccicheck" can be done instantaneously _and_ the spatch machinery > is just as reliable as C compilers. > [...] > Now we do not live in that ideal world and [...] > such a series will have zero > chance of landing in 'pu', unless

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-22 Thread Junio C Hamano
SZEDER Gábor writes: > I don't really like how this or the previous RFC patch series deal > with semantic patches (or how some past patch series dealt with them, > for that matter), for various reasons: > ... > How about introducing the concept of "pending" semantic patches, > stored in

Re: New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-22 Thread Stefan Beller
On Mon, Oct 22, 2018 at 10:39 AM SZEDER Gábor wrote: > > On Tue, Oct 16, 2018 at 04:35:31PM -0700, Stefan Beller wrote: > > the last patch (applying the semantic patches) has been omitted as that > > would produce a lot of merge conflicts. Without that patch, this merges > > cleanly to next. > >

New semantic patches vs. in-flight topics [was: Re: [PATCH 00/19] Bring more repository handles into our code base]

2018-10-22 Thread SZEDER Gábor
On Tue, Oct 16, 2018 at 04:35:31PM -0700, Stefan Beller wrote: > the last patch (applying the semantic patches) has been omitted as that > would produce a lot of merge conflicts. Without that patch, this merges > cleanly to next. > > As for when to apply the semantic patches, I wondered if we

Re: [PATCH 00/19] Bring more repository handles into our code base

2018-10-19 Thread Junio C Hamano
Stefan Beller writes: > This rerolls sb/more-repo-in-api. > It applies on nd/the-index merged with ds/reachable and is available via > git fetch https://github.com/stefanbeller/git object-store-final-3 Thanks. Luckily we have both of these prerequisites in 'master' now, o hopefully this

Re: [PATCH 00/19] Bring more repository handles into our code base

2018-10-17 Thread Stefan Beller
On Wed, Oct 17, 2018 at 5:41 AM Derrick Stolee wrote: > > On 10/16/2018 7:35 PM, Stefan Beller wrote: > > > > This series takes another approach as it doesn't change the signature > > of > > functions, but introduces new functions that can deal with arbitrary > > repositories,

Re: [PATCH 00/19] Bring more repository handles into our code base

2018-10-17 Thread Derrick Stolee
On 10/16/2018 7:35 PM, Stefan Beller wrote: This series takes another approach as it doesn't change the signature of functions, but introduces new functions that can deal with arbitrary repositories, keeping the old function signature around using a shallow wrapper.

[PATCH 00/19] Bring more repository handles into our code base

2018-10-16 Thread Stefan Beller
This rerolls sb/more-repo-in-api. It applies on nd/the-index merged with ds/reachable and is available via git fetch https://github.com/stefanbeller/git object-store-final-3 I addressed all of Jonathans comments, see range-diff below; the last patch (applying the semantic patches) has been

Re: [RFC PATCH 00/19] Bring more repository handles into our code base

2018-10-12 Thread Stefan Beller
On Fri, Oct 12, 2018 at 11:50 AM Jonathan Nieder wrote: > > It appears that some patches use a the_index-style > NO_THE_REPOSITORY_COMPATIBILITY_MACROS backward compatibility synonym > and others don't. Can you say a little more about this aspect of the > approach? Would the compatibility

Re: [RFC PATCH 00/19] Bring more repository handles into our code base

2018-10-12 Thread Jonathan Nieder
Hi, Stefan Beller wrote: > This applies on nd/the-index (b3c7eef9b05) and is the logical continuation of > the object store series, which I sent over the last year. > > The previous series did take a very slow and pedantic approach, > using a #define trick, see cfc62fc98c for details, but it

Re: [RFC PATCH 00/19] Bring more repository handles into our code base

2018-10-11 Thread Junio C Hamano
Stefan Beller writes: > Additionally each patch adds a semantic patch, that would port from the old to > the new function. These semantic patches are all applied in the very last > patch, > but we could omit applying the last patch if it causes too many merge > conflicts > and trickl in the

Re: [RFC PATCH 00/19] Bring more repository handles into our code base

2018-10-11 Thread Jonathan Tan
> This series takes another approach as it doesn't change the signature of > functions, but introduces new functions that can deal with arbitrary > repositories, keeping the old function signature around using a shallow > wrapper. > > Additionally each patch adds a semantic patch, that would

[RFC PATCH 00/19] Bring more repository handles into our code base

2018-10-11 Thread Stefan Beller
This applies on nd/the-index (b3c7eef9b05) and is the logical continuation of the object store series, which I sent over the last year. The previous series did take a very slow and pedantic approach, using a #define trick, see cfc62fc98c for details, but it turns out, that it doesn't work: