@section Cloning the source tree
@example
-git clone git://source.ffmpeg.org/ffmpeg <target>
+git clone https://git.ffmpeg.org/ffmpeg.git <target>
@end example
This will put the FFmpeg sources into the directory @var{<target>}.
git add [-i|-p|-A] <filenames/dirnames>
@end example
-Make sure you have told Git your name and email address
+Make sure you have told Git your name, email address and GPG key
@example
git config --global user.name "My Name"
git config --global user.email my@@email.invalid
+git config --global user.signingkey ABCDEF0123245
+@end example
+
+Enable signing all commits or use -S
+
+@example
+git config --global commit.gpgsign true
@end example
Use @option{--global} to set the global configuration for all your Git checkouts.
or set by one of the following environment variables:
@var{GIT_EDITOR}, @var{VISUAL} or @var{EDITOR}.
-Log messages should be concise but descriptive. Explain why you made a change,
-what you did will be obvious from the changes themselves most of the time.
-Saying just "bug fix" or "10l" is bad. Remember that people of varying skill
-levels look at and educate themselves while reading through your code. Don't
-include filenames in log messages, Git provides that information.
+@section Writing a commit message
+
+Log messages should be concise but descriptive.
+
+The first line must contain the context, a colon and a very short
+summary of what the commit does. Details can be added, if necessary,
+separated by an empty line. These details should not exceed 60-72 characters
+per line, except when containing code.
-Possibly make the commit message have a terse, descriptive first line, an
-empty line and then a full description. The first line will be used to name
+Example of a good commit message:
+
+@example
+avcodec/cbs: add a helper to read extradata within packet side data
+
+Using ff_cbs_read() on the raw buffer will not parse it as extradata,
+resulting in parsing errors for example when handling ISOBMFF avcC.
+This helper works around that.
+@end example
+
+@example
+ptr might be NULL
+@end example
+
+If the summary on the first line is not enough, in the body of the message,
+explain why you made a change, what you did will be obvious from the changes
+themselves most of the time. Saying just "bug fix" or "10l" is bad. Remember
+that people of varying skill levels look at and educate themselves while
+reading through your code. Don't include filenames in log messages except in
+the context, Git provides that information.
+
+If the commit fixes a registered issue, state it in a separate line of the
+body: @code{Fix Trac ticket #42.}
+
+The first line will be used to name
the patch by @command{git format-patch}.
+Common mistakes for the first line, as seen in @command{git log --oneline}
+include: missing context at the beginning; description of what the code did
+before the patch; line too long or wrapped to the second line.
+
@section Preparing a patchset
@example
where @var{$SHA1} is the commit hash from the @command{git log} output.
+@chapter gpg key generation
+
+If you have no gpg key yet, we recommend that you create a ed25519 based key as it
+is small, fast and secure. Especially it results in small signatures in git.
+
+@example
+gpg --default-new-key-algo "ed25519/cert,sign+cv25519/encr" --quick-generate-key "human@@server.com"
+@end example
+
+When generating a key, make sure the email specified matches the email used in git as some sites like
+github consider mismatches a reason to declare such commits unverified. After generating a key you
+can add it to the MAINTAINER file and upload it to a keyserver.
+
@chapter Pre-push checklist
Once you have a set of commits that you feel are ready for pushing,
projects / platform / upstream / ffmpeg.git / blobdiff