Ye Xiaolong <xiaolong.ye@xxxxxxxxx> writes: > For the info starts with "base-commit: <xxx> ...", robot would know it > is reliable base commit, it would just checkout it and apply the prerequisite > patches and patchset for the work. > > For the info starts with "parent-commit: <xxx>; parent-patch-id: <xxx>", > there are 3 situations 0day robot would need to handle: It all depends on how you are computing this "parent-commit" thing. When I reviewed the patch that implemented the fallback, my impression was that it wasn't computing anything relevant, but just was picking one of the random commit nearby in the history. Assuming that it is not the case, and it is computing something sensible, then I still do not see a point in marking these guessed ones differently as "parent-commit" (not "base-commit"). After all, a "base-commit" that was explicitly specified by the user can be something that is inappropriate (e.g. the user may have thought the base was a well-known one when his work was built on top of an early draft of the patch that was later tweaked), so recipients of the patch series need to be prepared to deal with a bogus base anyway. > 2) parent commit is well-known in-flight patch, since 0day maintains the > database of in-flight patches indexed by their patch-ids and > commit-ids(of the git tree mentioned below), it also exports a git tree > which holds all in-flight patches, where each patchset map to a new branch: > > https://github.com/0day-ci/linux/branches > > 0day will find that patch in database by parent patch id, then do the > checkout and apply work. If a user starts from some solid base, applies a well-known in-flight series, and builds his series on it and sends his series out, and the base is identified by the patch-id of the last patch of the in-flight series, then from that "parent patch-id" the robot can find a commit that is the result of applying the same in-flight series on top of some other solid base, as there is no coordination between the user and 0day-ci system. I would imagine that the difference between the bases do matter--otherwise you wouldn't be building this elaborate "base-commit" system that rejects the notion that it is not sufficient for patches to textually apply cleanly and insists that they have to be applied to exactly one known state. So, I am not sure why you think "patch-id" is a good way to identify the commit to be based on. > In practice, most developers may not feed exact commit id by --base=<xxx> > regularly when using git format-patch, this "showing parent commit" solution > could save developers' energy and reach a high coverage in the meantime. So, while I understand the desire and wish, I am not convinced "as a fallback, use parent patch-id and guess where to apply" is a good apprach to make the wish come true. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html