On 02-11-2026 15:42, Krzysztof Kozlowski wrote: > On 02/11/2026 11:08, Ekansh Gupta wrote: >> On 02-11-2026 14:23, Krzysztof Kozlowski wrote: >>> On 01/11/2026 23:21, Ekansh Gupta wrote: >>>> drivers/accel/qda/qda_soc.c | 66 ++ >>>> drivers/accel/qda/qda_soc.h | 61 ++ >>>> drivers/misc/Kconfig | 1 + >>>> include/uapi/drm/qda_accel.h | 282 +++++++ >>>> 33 files changed, 5877 insertions(+), 1 deletion(-) >>>> --- >>>> base-commit: 7649ba73f9e7e1e04d0b46213e39c79ae09dd55c >>>> change-id: 20261102-v4-e8feb321263f >>> >>> What is happening here? How are we supposed to work with this? >>> >>> v1: 20260223-qda-firstpost-4ab05249e2cc >>> v2: 20260519-qda-series-78c2bf0ed78b >>> v2 again: 20260817-qda-v2-78e2d1f10529 >>> >>> And now completely different one? >>> >>> This makes the change id completely unusable. b4 diff obviously does not >>> work. Any tracking of this does not work. >>> >>> NAK, really, I already complained internally months ago about such >>> practice, so apparently not enough. >>> >>> Best regards, >>> Krzysztof >> >> Sorry about this. I lost the original b4 branch and re-enrolled the > > You lost original branch four times. It's not a coincidence, it's not > random data loss because then after first loss you would solve the > problem. It's a broken workflow. > > > Best regards, > Krzysztof
You are right, and I'm not going to call it data loss again. I started each posting from a new tree and re-enrolled the series every time, which is what produced a new change-id for every revision. I've changed how I work so this cannot happen again: - one long-lived tree and one b4 branch for this series, used for all future revisions; - before every b4 send, a check that the change-id is still 20260817-qda-v2-78e2d1f10529. v5 will continue from that change-id, with the v3 and v4 postings recorded in its history.
