diff options
Diffstat (limited to 'third_party/git/Documentation/SubmittingPatches')
| -rw-r--r-- | third_party/git/Documentation/SubmittingPatches | 35 |
1 files changed, 21 insertions, 14 deletions
diff --git a/third_party/git/Documentation/SubmittingPatches b/third_party/git/Documentation/SubmittingPatches index 6d589e118c17..291b61e26213 100644 --- a/third_party/git/Documentation/SubmittingPatches +++ b/third_party/git/Documentation/SubmittingPatches @@ -3,8 +3,9 @@ Submitting Patches == Guidelines -Here are some guidelines for people who want to contribute their code -to this software. +Here are some guidelines for people who want to contribute their code to this +software. There is also a link:MyFirstContribution.html[step-by-step tutorial] +available which covers many of these same guidelines. [[base-branch]] === Decide what to base your work on. @@ -18,7 +19,7 @@ change is relevant to. base your work on the tip of the topic. * A new feature should be based on `master` in general. If the new - feature depends on a topic that is in `pu`, but not in `master`, + feature depends on a topic that is in `seen`, but not in `master`, base your work on the tip of that topic. * Corrections and enhancements to a topic not yet in `master` should @@ -27,7 +28,7 @@ change is relevant to. into the series. * In the exceptional case that a new feature depends on several topics - not in `master`, start working on `next` or `pu` privately and send + not in `master`, start working on `next` or `seen` privately and send out patches for discussion. Before the final merge, you may have to wait until some of the dependent topics graduate to `master`, and rebase your work. @@ -37,7 +38,7 @@ change is relevant to. these parts should be based on their trees. To find the tip of a topic branch, run `git log --first-parent -master..pu` and look for the merge commit. The second parent of this +master..seen` and look for the merge commit. The second parent of this commit is the tip of the topic branch. [[separate-commits]] @@ -142,19 +143,25 @@ archive, summarize the relevant points of the discussion. [[commit-reference]] If you want to reference a previous commit in the history of a stable -branch, use the format "abbreviated sha1 (subject, date)", -with the subject enclosed in a pair of double-quotes, like this: +branch, 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) noticed that ... .... The "Copy commit summary" command of gitk can be used to obtain this -format, or this invocation of `git show`: +format (with the subject enclosed in a pair of double-quotes), or this +invocation of `git show`: .... - git show -s --date=short --pretty='format:%h ("%s", %ad)' <commit> + git show -s --pretty=reference <commit> +.... + +or, on an older version of Git without support for --pretty=reference: + +.... + git show -s --date=short --pretty='format:%h (%s, %ad)' <commit> .... [[git-tools]] @@ -372,9 +379,9 @@ such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". Some parts of the system have dedicated maintainers with their own repositories. -- `git-gui/` comes from git-gui project, maintained by Pat Thoyts: +- `git-gui/` comes from git-gui project, maintained by Pratyush Yadav: - git://repo.or.cz/git-gui.git + https://github.com/prati0100/git-gui.git - `gitk-git/` comes from Paul Mackerras's gitk project: @@ -417,7 +424,7 @@ help you find out who they are. and cooked further and eventually graduates to `master`. In any time between the (2)-(3) cycle, the maintainer may pick it up -from the list and queue it to `pu`, in order to make it easier for +from the list and queue it to `seen`, in order to make it easier for people play with it without having to pick up and apply the patch to their trees themselves. @@ -428,7 +435,7 @@ their trees themselves. master. `git pull --rebase` will automatically skip already-applied patches, and will let you know. This works only if you rebase on top of the branch in which your patch has been merged (i.e. it will not - tell you if your patch is merged in pu if you rebase on top of + tell you if your patch is merged in `seen` if you rebase on top of master). * Read the Git mailing list, the maintainer regularly posts messages |