development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-08-25 10:45:59 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'jc/doc-submitting-patches-choice-of-base'

Browse source 
Extend the guidance to choose the base commit to build your work
on, and hint/nudge contributors to read others' changes.

* jc/doc-submitting-patches-choice-of-base:
  SubmittingPatchs: clarify choice of base and testing
This commit is contained in:
Junio C Hamano 2022-01-10 11:52:55 -08:00
parent 9b6eda0785 fdfae830f8
commit def8c6a05d
1 changed files with 39 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

53
Documentation/SubmittingPatches
View file

@ -19,8 +19,10 @@ change is relevant to.
base your work on the tip of the topic. base your work on the tip of the topic.
* A new feature should be based on `master` in general. If the new * A new feature should be based on `master` in general. If the new
feature depends on a topic that is in `seen`, but not in `master`, feature depends on other topics that are in `next`, but not in
base your work on the tip of that topic. `master`, fork a branch from the tip of `master`, merge these topics
to the branch, and work on that branch. You can remind yourself of
how you prepared the base with `git log --first-parent master..`.
* Corrections and enhancements to a topic not yet in `master` should * Corrections and enhancements to a topic not yet in `master` should
be based on the tip of that topic. If the topic has not been merged be based on the tip of that topic. If the topic has not been merged
@ -28,10 +30,10 @@ change is relevant to.
into the series. into the series.
* In the exceptional case that a new feature depends on several topics * In the exceptional case that a new feature depends on several topics
not in `master`, start working on `next` or `seen` privately and send not in `master`, start working on `next` or `seen` privately and
out patches for discussion. Before the final merge, you may have to send out patches only for discussion. Once your new feature starts
wait until some of the dependent topics graduate to `master`, and to stabilize, you would have to rebase it (see the "depends on other
rebase your work. topics" above).
* Some parts of the system have dedicated maintainers with their own * Some parts of the system have dedicated maintainers with their own
repositories (see the section "Subsystems" below). Changes to repositories (see the section "Subsystems" below). Changes to
@ -71,8 +73,13 @@ Make sure that you have tests for the bug you are fixing. See
[[tests]] [[tests]]
When adding a new feature, make sure that you have new tests to show When adding a new feature, make sure that you have new tests to show
the feature triggers the new behavior when it should, and to show the the feature triggers the new behavior when it should, and to show the
feature does not trigger when it shouldn't. After any code change, make feature does not trigger when it shouldn't. After any code change,
sure that the entire test suite passes. make sure that the entire test suite passes. When fixing a bug, make
sure you have new tests that break if somebody else breaks what you
fixed by accident to avoid regression. Also, try merging your work to
'next' and 'seen' and make sure the tests still pass; topics by others
that are still in flight may have unexpected interactions with what
you are trying to do in your topic.
Pushing to a fork of https://github.com/git/git will use their CI Pushing to a fork of https://github.com/git/git will use their CI
integration to test your changes on Linux, Mac and Windows. See the integration to test your changes on Linux, Mac and Windows. See the
@ -144,8 +151,21 @@ without external resources. Instead of giving a URL to a mailing list
archive, summarize the relevant points of the discussion. archive, summarize the relevant points of the discussion.
[[commit-reference]] [[commit-reference]]
If you want to reference a previous commit in the history of a stable
branch, use the format "abbreviated hash (subject, date)", like this: There are a few reasons why you may want to refer to another commit in
the "more stable" part of the history (i.e. on branches like `maint`,
`master`, and `next`):
. A commit that introduced the root cause of a bug you are fixing.
. A commit that introduced a feature that you are enhancing.
. A commit that conflicts with your work when you made a trial merge
of your work into `next` and `seen` for testing.
When you reference a commit on a more stable branch (like `master`,
`maint` and `next`), use the format "abbreviated hash (subject,
date)", like this:
.... ....
Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30) Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
@ -259,9 +279,11 @@ Please make sure your patch does not add commented out debugging code,
or include any extra files which do not relate to what your patch or include any extra files which do not relate to what your patch
is trying to achieve. Make sure to review is trying to achieve. Make sure to review
your patch after generating it, to ensure accuracy. Before your patch after generating it, to ensure accuracy. Before
sending out, please make sure it cleanly applies to the `master` sending out, please make sure it cleanly applies to the base you
branch head. If you are preparing a work based on "next" branch, have chosen in the "Decide what to base your work on" section,
that is fine, but please mark it as such. and unless it targets the `master` branch (which is the default),
mark your patches as such.
[[send-patches]] [[send-patches]]
=== Sending your patches. === Sending your patches.
@ -365,7 +387,10 @@ Security mailing list{security-ml-ref}.
Send your patch with "To:" set to the mailing list, with "cc:" listing Send your patch with "To:" set to the mailing list, with "cc:" listing
people who are involved in the area you are touching (the `git people who are involved in the area you are touching (the `git
contacts` command in `contrib/contacts/` can help to contacts` command in `contrib/contacts/` can help to
identify them), to solicit comments and reviews. identify them), to solicit comments and reviews. Also, when you made
trial merges of your topic to `next` and `seen`, you may have noticed
work by others conflicting with your changes. There is a good possibility
that these people may know the area you are touching well.
:current-maintainer: footnote:[The current maintainer: gitster@pobox.com] :current-maintainer: footnote:[The current maintainer: gitster@pobox.com]
:git-ml: footnote:[The mailing list: git@vger.kernel.org] :git-ml: footnote:[The mailing list: git@vger.kernel.org]