> I did want to submit them one at a time. I really did. But one change
> necessitated another in order to keep things consistent, and it ended
> up like this, one single commit in my git tree.
You can still dice it up into small bits.
Having done this before a few times when I've ended up in the same
situation (either by my own lack of planning or by being handed a blob by
and told my job is to sort it out) a few tips.
First start with the trivial bits - for example you can easily pull out
patches like
1. Add packed to dats structures that match the wire format
2. Correct the layout of sense iu
3. Add common initialisers
4. Clean up URB freeing
And while you are at it you can also lose changes by removing gratiutious
stuff like
-struct uas_dev_info {
+/* Lives in the SCSI host, hostdata points to it.
+ */
+struct uas_tport_info {
Now even if you hate the name or the qdepth field name you can deal with
it later once it is all nicely working. That would clean up the patch
noise a lot in itself
As you do that the rest becomes clearer and you can then recommit stuff
step by step. The patches need to tell a story which is "How we got from
A to B in small clearly logical steps without breaking anything on the
way"
The tagging mix should possibly also be discussed with the scsi list,
that may be the better place to fix it.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
