Re: [RFC][PATCH 0/32] SHA256 and SHA1 interoperability

"Eric W. Biederman" <ebiederm@xmission.com> writes:

Ah, no worries. By "integration" I did not mean "patches considered perfect, they are accepted, and are now part of the Git codebase".

All that happens when the patches become part of the 'master' branch, but before that, patches that prove testable and worthy of getting tested will be merged to the 'next' branch and spend about a week there. What I meant to refer to is a step _before_ that, i.e. before the patches probe to be testable. New patches first appear on the 'seen' branch that merges "everything else" to see the interaction with all the topics "in flight" (i.e. not yet in 'master'). The 'seen' branch is reassembled from the latest iteration of the patches twice of thrice per day, and some patches are merged to 'next' and down to 'master', these "merging to prepare 'master', 'next' and 'seen' branches for publishing" was what I meant by "integration". In short, being queued on 'seen' does not mean all that much. It gives project participants an easy access to view how topics look in the larger picture, potentially interacting with other topics in flight, but the patches in there can be replaced wholesale or even dropped if they do not turn out to be desirable.

I resolved textual conflicts and also compiler detectable semantic conflicts (e.g. some in-flight topics may have added callsites to a function your topic changes the function sigunature, or vice versa) to the point that the result compiles while merging this topic to 'seen', but tests are broken the big time, it seems, even though the topic by itself seems to pass the tests standalone.

Nice.