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>
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>
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>
"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>
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>
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>
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>
* 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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Separate things to be checked when making commits, and things
to be checked when sending patches.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/SubmittingPatches: Add note that all user interface changes
should include associated documentation updates.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It seems that some people prefer a short list to a long text. But even for
the latter group, a quick reminder list is useful. So, add a check list to
Documentation/SubmittingPatches of what to do to get your patch accepted.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As discussed on git mailing list let's teach the reader about
the possiblity to have automatically signed off the commit running
the git-commit -s command
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Setting the wraplength to zero keeps the bird from trimming WS.
Signed-off-by: <gitzilla@gmail.com>
(cherry picked from 1d535d525d6a0ddddc3755065d721278bc5f0aff commit)
- It does not matter how I read git list. What matters is that
I do not necessarily read everything on it.
- Talk a bit about how to use applymbox to check one's own
patches.
- Talk a bit about PGP signed patches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not that I have stricter patch submission standard than ordinary
projects, I wanted to have it to make sure people understand
what they are doing when they add their own Signed-off-by line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
