Lines Matching refs:what

133 Once the problem is established, describe what you are actually doing
173 the commit, to make it easier for reviewers to know what it is about.
375 understands what is going on.
377 Be sure to tell the reviewers what changes you are making and to thank them
410 To improve tracking of who did what, especially with patches that can
482 here's what we see in a 3.x-stable release:
490 And here's what might appear in an older kernel once a patch is backported:
654 characters, and it must describe both what the patch changes, as well
656 succinct and descriptive, but that is what a well-written summary
702 a diffstat, to show what files have changed, and the number of
707 which describe what has changed between the v1 and v2 version of the
742 A pull request should also include an overall message saying what will be