Junio C Hamano [off-list ref] writes:
I have to say that this was a painful topic to integrate.
As you may know, the mk/use-size-t-in-zlib topic is being retracted
and getting rerolled as a larger size_t series, most of which still
needs help in reviewing.
The jt/sha1-file-cleanup topic is the only one among the other four
that are still not in 'next', and I think that topic, as well as the
other three, are all good and serve as a good base to build on top.
So I first rebuilt your patches on top of these four topics. This
took some time but it wasn't all that painful.
... but it turns out that I screwed it up in at least one place,
making Linux32 build fail (Thanks Lars and folks who pushed hard to
arrange Travis to build all my pushes to 'pu'). I'm pushing out my
second attempt. Let's see how it goes.
A change like this that only moves code around without changing
anything is painful to everybody to keep around, as nobody can
safely touch the affected code while it is in flight. On the other
hand, as long as it is only moving code around, such a change is
reasonably safe, and it is relatively easy to ensure that there is
no change other than code movement is involved. So let's
(1) make sure that the topics this depends on are sound by
re-reading them once again, and merge them quickly down to
'master';
(2) merge this topic to 'next', optionally after rebasing it on
'master', after (1) happens; and
(3) quickly merge it to 'master', to get it over with.
In the meantime we'd need to refrain from taking code that touch
things that are moved by this series.
I plan to be offline for a week or so near the end of this month, so
I am hoping that we can do all of the above before that. That may
make us break our usual "tip of the 'master' is more stable and
robust than any released version" promise by potentially leaving it
broken for a while, but nobody can build on top of a fluid codebase
that is in the process of moving things around in a big way, so it
might not be such a bad idea to make it coincide with the period
when the tree must become quiescent due to my being offline. We'll
see.
Thanks.
On Sat, 19 Aug 2017 23:40:33 -0700
Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
I have to say that this was a painful topic to integrate.
As you may know, the mk/use-size-t-in-zlib topic is being retracted
and getting rerolled as a larger size_t series, most of which still
needs help in reviewing.
The jt/sha1-file-cleanup topic is the only one among the other four
that are still not in 'next', and I think that topic, as well as the
other three, are all good and serve as a good base to build on top.
So I first rebuilt your patches on top of these four topics. This
took some time but it wasn't all that painful.
... but it turns out that I screwed it up in at least one place,
making Linux32 build fail (Thanks Lars and folks who pushed hard to
arrange Travis to build all my pushes to 'pu'). I'm pushing out my
second attempt. Let's see how it goes.
Thanks.
A change like this that only moves code around without changing
anything is painful to everybody to keep around, as nobody can
safely touch the affected code while it is in flight. On the other
hand, as long as it is only moving code around, such a change is
reasonably safe, and it is relatively easy to ensure that there is
no change other than code movement is involved. So let's
(1) make sure that the topics this depends on are sound by
re-reading them once again, and merge them quickly down to
'master';
I took a look and they look sound.
- rs/find-pack-entry-bisection resolves an issue first introduced in
commit 1f68855 ("[PATCH] Teach read_sha1_file() and friends about
packed git object store.", 2005-06-27), which already had that issue.
- jk/drop-sha1-entry-pos is some code deletion.
- rs/unpack-entry-leakfix ensures that delta_stack is freed. This
function does not (for example) expose the destination of delta_stack
to its caller, so it is correct that delta_stack should be freed
unless it points to the local buffer, just like in the success case.
- jt/sha1-file-cleanup (my patches) still looks OK to me.
In your latest "What's cooking" (Aug 2017, #04; Fri, 18), you mentioned
that the first 3 will be merged to master, and the 4th will be merged to
next.
I didn't look at mk/use-size-t-in-zlib, which (as you said) is still
under review.
(2) merge this topic to 'next', optionally after rebasing it on
'master', after (1) happens; and
(3) quickly merge it to 'master', to get it over with.
In the meantime we'd need to refrain from taking code that touch
things that are moved by this series.
I plan to be offline for a week or so near the end of this month, so
I am hoping that we can do all of the above before that. That may
make us break our usual "tip of the 'master' is more stable and
robust than any released version" promise by potentially leaving it
broken for a while, but nobody can build on top of a fluid codebase
that is in the process of moving things around in a big way, so it
might not be such a bad idea to make it coincide with the period
when the tree must become quiescent due to my being offline. We'll
see.
Thanks.