summaryrefslogtreecommitdiff
path: root/Documentation/SubmittingPatches
AgeCommit message (Collapse)AuthorFilesLines
2013-01-11Merge branch 'jc/submittingpatches' into maintLibravatar Junio C Hamano1-84/+91
* jc/submittingpatches: SubmittingPatches: give list and maintainer addresses SubmittingPatches: remove overlong checklist SubmittingPatches: mention subsystems with dedicated repositories SubmittingPatches: who am I and who cares?
2013-01-02SubmittingPatches: give list and maintainer addressesLibravatar Junio C Hamano1-2/+6
We told readers to "send it to the list" (or the maintainer) without telling what addresses are to be used. Correct this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-02SubmittingPatches: remove overlong checklistLibravatar Junio C Hamano1-76/+61
The section is no longer a concise checklist. It also talks about things that are not covered in the "Long version" text, which means people need to read both, covering more or less the same thing in different phrasing. Fold the details into the main text and remove the section. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-01SubmittingPatches: mention subsystems with dedicated repositoriesLibravatar Junio C Hamano1-0/+24
These were only mentioned in periodical "A note from the maintainer" posting and not in the documentation suite. SubmittingPatches has a section to help contributors decide on what commit to base their changes, which is the most suitable place for this information. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-01SubmittingPatches: who am I and who cares?Libravatar Junio C Hamano1-8/+2
The introductory text in the "long version" talks about the origin of this document with "I started ...", but it is unclear who that I is, and more importantly, it is not interesting how it was started. Just state the purpose of the document to help readers decide if it is releavant to them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-21Merge branch 'as/doc-for-devs'Libravatar Junio C Hamano1-13/+8
It might be a better idea to move the text the bottom one adds to the extended description from the quick checklist part. * as/doc-for-devs: Documentation: move support for old compilers to CodingGuidelines SubmittingPatches: add convention of prefixing commit messages
2012-12-16Documentation: move support for old compilers to CodingGuidelinesLibravatar Adam Spiers1-13/+0
The "Try to be nice to older C compilers" text is clearly a guideline to be borne in mind whilst coding rather than when submitting patches. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-16SubmittingPatches: add convention of prefixing commit messagesLibravatar Adam Spiers1-0/+8
Conscientious newcomers to git development will read SubmittingPatches and CodingGuidelines, but could easily miss the convention of prefixing commit messages with a single word identifying the file or area the commit touches. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-25Doc SubmittingPatches: Mention --notes option after "cover letter"Libravatar Philip Oakley1-1/+2
The git format-patch --notes option can now insert the commit notes after the three dashes. Mention this after the regular cover letter guidance for submitting patches. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff King <peff@peff.net>
2011-09-11SubmittingPathces: remove Cogito referenceLibravatar Sverre Rabbelier1-2/+1
Removing Cogito leaves just git and StGit, which is a rather incomplete list of git diff tools available. Sidestep the problem of deciding what tools to mention by not mentioning any. Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: publicize hints for sending patches with GMailLibravatar Jonathan Nieder1-52/+2
The hints in SubmittingPatches about stopping GMail from clobbering patches are widely useful both as examples of "git send-email" and "git imap-send" usage. Move the documentation to the appropriate places. While at it, don't encourage storing passwords in config files. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: publicize KMail hints for sending patches inlineLibravatar Jonathan Nieder1-20/+2
These hints are in git's private SubmittingPatches document but a wider audience might be interested. Move them to the "git format-patch" manpage. I'm not sure what gotchas these hints are meant to work around. They might be completely false. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: hints for sending patches inline with ThunderbirdLibravatar Jonathan Nieder1-80/+1
The standard reference for this information is the article "Plain text e-mail - Thunderbird#Completely_plain_email" at kb.mozillazine.org, but the hints hidden away in git's SubmittingPatches file are more complete. Move them to the "git format-patch" manual so they can be installed with git and read by a wide audience. While at it, make some tweaks: - update "Approach #1" so it might work with Thunderbird 3; - remove ancient version numbers from the descriptions of both approaches so current readers might have more reason to complain if they don't work. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-15Documentation: explain how to check for patch corruptionLibravatar Jonathan Nieder1-44/+14
SubmittingPatches has some excellent advice about how to check a patch for corruption before sending it off. Move it to the format-patch manual so it can be installed with git's documentation for use by people not necessarily interested in the git project's practices. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13remove doubled words, e.g., s/to to/to/, and fix related typosLibravatar Jim Meyering1-2/+1
I found that some doubled words had snuck back into projects from which I'd already removed them, so now there's a "syntax-check" makefile rule in gnulib to help prevent recurrence. Running the command below spotted a few in git, too: git ls-files | xargs perl -0777 -n \ -e 'while (/\b(then?|[iao]n|i[fst]|but|f?or|at|and|[dt])\s+\1\b/gims)' \ -e '{$n=($` =~ tr/\n/\n/ + 1); ($v=$&)=~s/\n/\\n/g;' \ -e 'print "$ARGV:$n:$v\n"}' Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-08SubmittingPatches: clarify the expected commit log descriptionLibravatar Junio C Hamano1-8/+18
Earlier, 47afed5 (SubmittingPatches: itemize and reflect upon well written changes, 2009-04-28) added a discussion on the contents of the commit log message, but the last part of the new paragraph didn't make much sense. Reword it slightly to make it more readable. Update the "quicklist" to clarify what we mean by "motivation" and "contrast". Also mildly discourage external references. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-06SubmittingPatches: Document some extra tags used in commit messagesLibravatar Ramkumar Ramachandra1-6/+15
Document the meanings of the tags "Reported-by:", "Acked-by:", "Reviewed-by:" and "Tested-by:" clearly. Also mention that the user is free to use any custom tags. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Liked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-28SubmittingPatches: Cite the 50 char subject limitLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Change the SubmittingPatches recommendations to mention the 50 character soft limit on patch subject lines. 50 characters is the soft limit mentioned in git-commit(1) and gittutorial(7), it's also the point at which Gitweb, GitHub and various other Git front ends start abbreviating the commit message. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-28SubmittingPatches: Clarify the Signed-off-by rulesLibravatar Ævar Arnfjörð Bjarmason1-5/+3
The wording of the Signed-off-by rules could be read as stating that S-O-B should only be added when the submitter considered the patch ready for inclusion in git.git. We also want Signed-off-by to be used for e.g. RFC patches, in case someone wants to dig an old patch out of the archive and improve it. Change the wording to recommend a Signed-off-by for all submitted patches. The problem with the wording came up in the "[PATCH/RFC] Hacky version of a glob() driven config include" thread[1]. Bert Wesarg suggested[2] that it be removed to avoid confusion, which this change implements. 1. <1273180440-8641-1-git-send-email-avarab@gmail.com> 2. <AANLkTimziTKL13VKIOcaS1TX1F_xvTVjH8Q398Yx36Us@mail.gmail.com> Suggested-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Documentation/SubmittingPatches: Fix typo in GMail section Documentation/config: describe status.submodulesummary
2010-05-31Documentation/SubmittingPatches: Fix typo in GMail sectionLibravatar Tim Henigan1-1/+1
Commit e498257d introduced a typo while improving the GMail section of SubmittingPatches. Signed-off-by: Tim Henigan <tim.henigan@gmail.com> Acked-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-25Merge branch 'maint'Libravatar Junio C Hamano1-19/+21
* maint: Documentation/SubmittingPatches: clarify GMail section and SMTP show-branch: use DEFAULT_ABBREV instead of 7 t7502-commit: fix spelling test get_git_work_tree() return value for NULL
2010-05-25Documentation/SubmittingPatches: clarify GMail section and SMTPLibravatar Michael J Gruber1-19/+21
We keep getting mangled submissions from GMail's web interface. Try to be more proactive in SubmittingPatches by - pointing to MUA specific instructions early on, - structuring the GMail section more clearly, - putting send-email/SMTP before imap-send/IMAP. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21Merge branch 'rr/doc-submitting'Libravatar Junio C Hamano1-11/+38
* rr/doc-submitting: SubmittingPatches: Add new section about what to base work on
2010-04-18SubmittingPatches: Add new section about what to base work onLibravatar Ramkumar Ramachandra1-11/+38
Add a section 0 explaining which commit to base patches on. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-07SubmittingPatches: update GMail sectionLibravatar Junio C Hamano1-11/+24
Even if you use imap-send to throw your drafts in the outbox, using their web interface will mangle your patches. Clarify that the imap-send is meant to be used together with a real MUA that can use IMAP drafts, and remove instructions related to the web interface, which is irrelevant. Add description of send-email as an alternative. Use --cover-letter, and do not use -C nor --no-color, on the example command line for format-patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-31SubmittingPatches: hints to know the status of a submitted patch.Libravatar Matthieu Moy1-0/+14
"What happened to my patch" is pretty much a FAQ on the Git mailing list, it deserves a few paragraphs in SubmittingPatches... Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-28SubmittingPatches: itemize and reflect upon well written changesLibravatar Sam Vilain1-1/+13
The SubmittingPatches file was trimmed down from a somewhat overwhelming set of requirements from the Linux Kernel equivalent; however perhaps a little of it can be returned without making the text too long. Signed-off-by: Sam Vilain <sam@vilain.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04Google has renamed the imap folderLibravatar John Tapsell1-0/+10
Also add a comment that the web interface wraps the lines Signed-off-by: John Tapsell <johnflux@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-12Update documentation to add further information about using Thunderbird with ↵Libravatar Jeremy White1-0/+27
git-imap-send. Signed-off-by: Jeremy White <jwhite@codeweavers.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19Merge branch 'maint' to sync with GIT 1.6.0.6Libravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19SubmittingPatches: mention the usage of real name in Signed-off-by: linesLibravatar Miklos Vajna1-0/+3
Especially with something that is supposed to hopefully have some legal value down the line if somebody starts making noises, it really would be nice to have a real person to associate things with. Suggest this in the SubmittingPatches document. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-02Merge branch 'maint'Libravatar Junio C Hamano1-0/+27
* maint: Start 1.6.0.4 cycle add instructions on how to send patches to the mailing list with Gmail Documentation/gitattributes: Add subsection header for each attribute git send-email: avoid leaking directory file descriptors. send-pack: do not send out single-level refs such as refs/stash fix overlapping memcpy in normalize_absolute_path pack-objects: avoid reading uninitalized data correct cache_entry allocation Conflicts: RelNotes
2008-11-01add instructions on how to send patches to the mailing list with GmailLibravatar Tom Preston-Werner1-0/+27
Gmail is one of the most popular email providers in the world. Now that Gmail supports IMAP, sending properly formatted patches via `git imap-send` is trivial. This section in SubmittingPatches explains how to do so. Signed-off-by: Tom Preston-Werner <tom@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-19SubmittingPatches: fix a typoLibravatar Jim Meyering1-1/+1
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-21Rename .git/rebase to .git/rebase-applyLibravatar Johannes Schindelin1-1/+1
With git-am, it sounds awkward to have the patches in ".git/rebase/", but for technical reasons, we have to keep the same directory name for git-am and git-rebase. ".git/rebase-apply" seems to be a good compromise. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-15Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"Libravatar Johannes Schindelin1-1/+1
Since the files generated and used during a rebase are never to be tracked, they should live in $GIT_DIR. While at it, avoid the rather meaningless term "dotest" to "rebase", and unhide ".dotest-merge". This was wished for on the mailing list, but so far unimplemented. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-19Add a helper script to send patches with Mozilla ThunderbirdLibravatar Lukas Sandström1-0/+5
The script appp.sh can be used with the External Editor extension for Mozilla Thunderbird in order to be able to send inline patches in an easy way. Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-16Documentation/SubmittingPatches - a suggested patch flowLibravatar Junio C Hamano1-0/+35
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-05Documentation/SubmittingPatches: What's Acked-by and Tested-by?Libravatar Junio C Hamano1-4/+12
We used to talk about "internal company procedures", but this document is about submitting patches to the git mailing list. More useful information is when to say Acked-by: and Tested-by:. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-05Documentation/SubmittingPatches: discuss first then submitLibravatar Junio C Hamano1-4/+5
This is something I've had in mind for some time. I get enough e-mails as-is, and I suspect the workflow to get list members involved would work better if we get the discussion concluded on the list first before patches hit my tree (even 'next'). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-05Documentation/SubmittingPatches: Instruct how to use [PATCH] Subject headerLibravatar Junio C Hamano1-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06Change from using email.com to example.com as example domain, as per RFC 2606.Libravatar David Symonds1-1/+1
Signed-off-by: David Symonds <dsymonds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-08SubmittingPatches: improve the 'Patch:' section of the checklistLibravatar Sergei Organov1-5/+4
There were 2 items "send patch to..." but having different set of addresses to send patch to. Merge them together and move the resulting item to the end of checklist. Signed-off-by: Sergei Organov <osv@javad.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-01Update my contact address as the maintainer.Libravatar Junio C Hamano1-1/+2
2007-06-07War on whitespaceLibravatar Junio C Hamano1-7/+7
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-02Update to SubmittingPatchesLibravatar Johannes Schindelin1-0/+4
Make people aware of our testsuite, and of non-ASCII encodings. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-24Remove git-applypatchLibravatar Junio C Hamano1-2/+2
The previous one removed git-applymbox, which was the sole user of this tool. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-21Merge branch 'maint-1.5.1' into maintLibravatar Junio C Hamano1-0/+13
* maint-1.5.1: git-status: respect core.excludesFile SubmittingPatches: mention older C compiler compatibility git-daemon: don't ignore pid-file write failure
2007-05-21SubmittingPatches: mention older C compiler compatibilityLibravatar Johannes Schindelin1-0/+13
We do not appreciate C99 initializers, declarations after statements, or "0" instead of "NULL". Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 01:50:46 +0000