Hi Krzysztof, You might want to familiarise yourself with the drm tree development procedures before weighing in, and snarky comments like the final one are not appreciated on this list or in this community. The drm next trees are never rebased (only in super rare emergencies), we never rebase next onto fixes, This leads to a number of things that are different from other workflows. I agree the duplicate SoB isn't great, but it's also not harmful, The cherry-pick thing is normal operating procedure unfortunately, we get told if we leave it out it causes problems later, so we add it in, and it resolves itself in the future when the next trees end up in Linus' tree. Thanks, Dave. > > > > 1. Duplicated committer SoB. > > You added SoB. No need to add two. It does not get stronger. You do not > > change the DCO rules by adding two SoBs. You cannot confirm something > > more or twice. Read DCO one more time... > > > > 2. Useless cherry pick SHA. > > fatal: bad object 97b6784753da06d9d40232328efc5c5367e53417 > > (Tried with repo having several maintainer repos and the linux-next) > > > > Only you have 97b6784753da06d9d40232328efc5c5367e53417. Maybe few other > > people as well, but all other do not. This does not bring any useful > > information, rather obfuscates public git history. > > ... and in case you claim that 97b6784753da06d9d40232328efc5c5367e53417 > is in drm-next, then your workflow is broken because: > 1. You will duplicate the same commit. One in drm-fixes and second in > drm-next. Just use git features, like branches and merges... First you > apply on fixes, then you merge it to next, for example. Or any other > sane way. > > 2. If you rebase drm-next on top of drm-fixes in some time in the > future, then that cherry-pick SHA will not work and will be totally useless. > > so either you create duplicate commits (that's how Intel gets stats?) or > you introduce to git history totally bogus SHAs... > > Best regards, > Krzysztof >
