Re: [PATCH v3 00/23] Move exported packfile funcs to its own file

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 19, 2017, 07:33 UTC
Message-ID: <xmqqk2209fm8.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <cover.1503094448.git.jonathantanmy@google.com>

Jonathan Tan <jonathantanmy@google.com> writes:

Show 29 quoted lines

>> 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.