Matthieu Moy <matthieu....@grenoble-inp.fr> writes: > Karthik Nayak <karthik....@gmail.com> writes: > >> On Mon, Oct 12, 2015 at 6:06 AM, Junio C Hamano <gits...@pobox.com> wrote: >>> Karthik Nayak <karthik....@gmail.com> writes: >>> >>>> On Fri, Oct 9, 2015 at 11:59 PM, Junio C Hamano <gits...@pobox.com> wrote: >>>> ... >>>> Also does it make sense to integrate these changes here? Or would you like >>>> to >>>> have another series on this? >>> >>> I do not think you would want to ask that question, as my answer >>> would most likely be "The most preferable would be a series to clean >>> up the existing codepath that deals with %(align) first, on top of >>> which everything in flight that is not yet in 'next' is rebased." >> >> Ah, but I might take a while to get there, So I'd rather push code which >> is almost ready and work on that slowly, if that's ok? > > That's OK to me. The "most preferable way" above would lead to a cleaner > history, but also more work for you and for me as a reviewer.
I do not think the cleanliness of the resulting history is of prime concern. At least, that was not where my preference came from. If you design a new infrastructure to help refactoring early (i.e. before adding many copies of code that need to be cleaned up later), it would make the work of reviewing of the design of the helper and refactoring using that helper smaller, not larger. And the new codepaths that use the helper would become easier to follow (otherwise we wouldn't be doing such a refactoring in the first place), making the reviews easier. That is where my preference comes from. There _is_ a sunk-cost that has already been invested in reviewing the older round that added code that needs to be cleaned up; there are some parts other than the "need to be cleaned-up" parts that we would feel confortable having in the reroll without having to re-review them. I do not know if that is a very high cost, though, especially for those who have already seen the previous rounds. Anyway, I wouldn't insist and we can go either way. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
