On Tue, Jan 12, 2021 at 06:15:11PM -0800, Junio C Hamano wrote: > Taylor Blau <me@xxxxxxxxxxxx> writes: > > > Did you want to queue these two topics separately? > > Unless it is a reasonable amount of certainty that the bottom topic > will not have to be rerolled, I'd rather not to have separate topics > on top of each other. Hmm. I certainly do not want to create any tedious work for you, but I do think that we're in a situation where the bottom topic is stable and the interesting discussion will happen in the newer topic. > It is tedious and error prone, having to rebase the old iteration of > the top topic on top when a new iteration of the bottom topic comes > out. I'd rather see that the top one get rerolled whenever the > bottom one gets rerolled to make life simpler. Indeed, my local v2 of the bottom topic requires the top topic to be rebased onto it, and so I'll plan to send a v2 of each tomorrow morning. > Even in a single topic, I would encourage people to put thet > foundational and preparatory work early so that we can make them > solidify before review really gets to later parts of the series. > > And when a series is structured like so, it is perfectly fine to say > something like: > > Here is a new iteration of the last 7 patches---the early 13 > patches are the same as the previous round, so reset the topic > to bb6414ab (packfile: prepare for the existence of '*.rev' > files, 2021-01-08) and then apply these 7. > > if you do not want to send all patches in a nontrivial series when > it gets updated. I am happy to do it this way if you would prefer. If so, you may want to rename this topic while queuing, since it is not just about a new revindex API, but rather about introducing the on-disk format. (I would suggest tb/on-disk-revindex, if you were looking for alternate names). If you agree that the bottom topic is stable, I'd prefer to send the top one separately. Otherwise, I can send both together. Let me know. > Thanks. Thanks, Taylor
