Lines Matching +full:- +full:- +full:no +full:- +full:git +full:- +full:commit
7 ----------------
9 - Patches should not mix code changes with code formatting changes
11 - Code patches should follow Mesa :doc:`coding
13 - Whenever possible, patches should only affect individual Mesa/Gallium
15 - Patches should never introduce build breaks and should be bisectable
16 (see ``Git bisect``.)
17 - Patches should be properly :ref:`formatted <formatting>`.
18 - Patches should be sufficiently :ref:`tested <testing>` before
20 - Patches should be :ref:`submitted <submit>` via a merge request for
26 ----------------
28 - Lines should be limited to 75 characters or less so that Git logs
29 displayed in 80-column terminals avoid line wrapping. Note that
30 ``git log`` uses 4 spaces of indentation (4 + 75 < 80).
31 - The first line should be a short, concise summary of the change
42 - Subsequent patch comments should describe the change in more detail,
47 i965: Remove end-of-thread SEND alignment code.
50 for Sandybridge (commit 077d01b6). There is no documentation saying this
51 is necessary, and removing it causes no regressions in piglit on any
54 - A "Signed-off-by:" line is not required, but not discouraged either.
55 - If a patch addresses an issue in GitLab, use the Closes: tag For
60 Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1
63 easier to get to the bug page from ``git log``
69 - If there have been several revisions to a patch during the review
77 there is no requirement to support native S8 for this,
88 - If someone tested your patch, document it with a line like this:
92 Tested-by: Joe Hacker <jhacker@foo.com>
94 - If the patch was reviewed (usually the case) or acked by someone,
99 Reviewed-by: Joe Hacker <jhacker@foo.com>
100 Acked-by: Joe Hacker <jhacker@foo.com>
102 - When updating a merge request add all the tags (``Acked-by:``, ``Reviewed-by:``,
103 ``Fixes:``, ``Backport-to:`` and/or other) to the commit messages.
110 ------------------
112 If a patch addresses a issue introduced with earlier commit, that
113 should be noted in the commit message. For example::
119 git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"
121 After that, using ``git fixes <sha1>`` will print the full line for you.
126 If you want a commit to be applied to a stable branch, you should add an
127 appropriate note to the commit message.
130 is the preferred way to nominate a commit that should be backported.
134 Alternatively, you may use the ``Backport-to:`` tag, as presented in the
137 Backport-to: 21.0
139 Multiple ``Backport-to:`` lines are allowed.
146 Cc: mesa-stable
147 Cc: 20.0 <mesa-stable>
148 CC: 20.0 19.3 <mesa-stable>
157 ---------------
173 to test this is to make use of the \`git rebase\` command, to run your
174 tests on each commit. Assuming your branch is based off
177 .. code-block:: sh
179 $ git rebase --interactive --exec "meson test -C build/" origin/main
186 ------------------
193 - Mesa changes affecting all drivers: mesa
194 - Hardware vendor specific code: AMD common, intel, ...
195 - Driver specific code: ANV, freedreno, i965, iris, radeonsi, RADV,
197 - Other tag examples: gallium, util
209 buildable and functional after every commit whenever you push the
213 there are no guarantees that a Mesa dev will independently take interest
218 - Make changes and update your branch based on feedback
219 - After an update, for the feedback you handled, close the feedback
222 - Old, stale MR may be closed, but you can reopen it if you still want
224 - You should periodically check to see if your MR needs to be rebased
225 - Make sure your MR is closed if your patches get pushed outside of
227 - Please send MRs from a personal fork rather than from the main Mesa
233 -----------------
236 Requests <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests>`__
244 Reviewed-by: Joe Hacker <jhacker@foo.com>
250 Acked-by: Joe Hacker <jhacker@foo.com>
258 With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
263 These Reviewed-by, Acked-by, and Tested-by tags should also be amended
266 When providing a Reviewed-by, Acked-by, or Tested-by tag in a GitLab MR,
271 `Reviewed-by: Joe Hacker <jhacker@example.com>`
276 Review by non-experts is encouraged. Understanding how someone else goes
285 ----------------------
291 Pushing (``git push``) directly to ``main`` is forbidden. This bypasses all
295 Do not use the "Merge"/"Merge when pipeline succeeds"/"Set to auto-merge"
298 We use a `custom script <https://gitlab.com/marge-org/marge-bot>`__ to manage
299 this, triggered by **assigning the MR** to the pseudo-user `@marge-bot
300 <https://gitlab.freedesktop.org/marge-bot>`__.
310 Nominating a commit for a stable branch
311 ---------------------------------------
316 - By adding the ``Fixes:`` tag in the commit message as described above, if you are fixing
317 a specific commit.
318 - By adding the ``Cc: mesa-stable`` tag in the commit message as described above.
319 - By submitting a merge request against the ``staging/year.quarter``
322 Please **DO NOT** send patches to mesa-stable@lists.freedesktop.org, it
334 ---------------------------------------------------
340 accepted and which are not. The stable-release manager is also given
343 - Patch must conform with the :ref:`Basic guidelines <guidelines>`
344 - Patch must have landed in main first. In case where the original
347 - It must not introduce a regression - be that build or runtime wise.
354 - Patch cannot be larger than 100 lines.
355 - Patches that move code around with no functional change should be
357 - Patch must be a bug fix and not a new feature.
360 An exception to this rule, are hardware-enabling "features". For
362 newly-developed hardware product can be accepted if they can be
365 - Patch must be reviewed, For example, the commit message has
366 Reviewed-by, Signed-off-by, or Tested-by tags from someone but the
368 - Performance patches are considered only if they provide information
373 :ref:`cherry-picked <pickntest>`. Alternatively the release
375 been rejected or would request a backport. The stable-release manager
376 may at times need to force-push changes to the stable branches, for
377 example, to drop a previously-picked patch that was later identified as
378 causing a regression). These force-pushes may cause changes to be lost
385 ---------------------------------------
387 By default merge conflicts are resolved by the stable-release manager.
400 Make sure to use ``git cherry-pick -x`` when cherry-picking the commits
401 from the main branch. This adds the "cherry picked from commit ..." line
402 to the commit message, to allow the release maintainters to mark those
407 ---------------------
412 .. code-block:: sh
415 apk add coreutils graphviz py3-clang clang-dev musl-dev linux-headers
419 sphinx-build -W -b html docs docs-html/
424 suggest a spelling-change, either during review or as a follow-up
425 merge-request.
428 .. _Sphinx: https://www.sphinx-doc.org/
430 Git tips
431 --------
433 - ``git rebase -i ...`` is your friend. Don't be afraid to use it.
434 - Apply a fixup to commit FOO.
436 .. code-block:: sh
438 git add ...
439 git commit --fixup=FOO
440 git rebase -i --autosquash ...
442 - Test for build breakage between patches e.g last 8 commits.
444 .. code-block:: sh
446 git rebase -i --exec="ninja -C build/" HEAD~8