Jonathan Tan <jonathanta...@google.com> writes:
>> You'd need to double check, but I think the topics that cause
>> trouble are rs/find-apck-entry-bisection and jk/drop-sha1-entry-pos;
>> you can start from v2.14.1 and merge these topics on top and then
>> build your change on top. That would allow you to start cooking
>> before both of them graduate to 'master', as I expect they are both
>> quick-to-next material. There might be other topics that interfere
>> with what you are doing, but you can easily find out what they are
>> if you do a trial merge to 'next' and 'pu' yourself.
>
> OK - in addition to the 2 you mentioned, I have found some others
> (likely added after you wrote that). The complete list is:
> - rs/find-pack-entry-bisection
> - jk/drop-sha1-entry-pos
> - jt/sha1-file-cleanup (formerly part of this set)
> - mk/use-size-t-in-zlib
> - rs/unpack-entry-leakfix
>
> I have merged all of these and rebased my patches on top.
>
> Other changes:
> - Used packfile.h instead of pack.h (following most people's
> preference)
> - Ensured that I added functions to packfile.h retaining the order they
> were originally in, so that if you run "git diff <base> --color-moved
> --patience", there are much fewer zebra stripes
>
> The merge base commit can be accessed online [1], if you need it.
>
> [1] https://github.com/jonathantanmy/git/commits/packmigrate
Thanks.
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.
The result cleanly merged to 'pu', I think, but it resulted in a
rather noisy conflict when I attempted to merge it to 'next'. I
want to see both of a merge to 'next' and a merge to 'pu' to be
reasonably clean for any topic to be viable [*1*]. Otherwise,
"initially queue in 'pu', then cook in 'next', and eventually
graduate to 'master'" workflow would not work well.
Anyway, I _think_ I finally got the conflict resolutions right for
merges of the topic to 'next', 'jch' and 'pu', so I will push the
result of merging to 'pu' out. This unfortunately makes Martin's
ongoing size_t topic unmergeable to any of the integration branches
as-is, but let's make sure that topic is reviewed properly first (I
haven't seen people comment much on the individual patches other
than just selected few).
[Footnote]
*1* There is an intermediate point between 'master' and 'pu' called
'jch', and I try to make sure any new topic to merge cleanly to
that branch, too, when accepting it. That is the branch I use
for everyday work as an early guinea-pig.
