Jonathan Tan <jonathantanmy@xxxxxxxxxx> 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.
