here on the technical/contents front, because the core GIT is
thousand times smaller ;-). So here is only the relevant bits.
+(0) Decide what to base your work on.
+
+In general, always base your work on the oldest branch that your
+change is relevant to.
+
+ - A bugfix should be based on 'maint' in general. If the bug is not
+ present in 'maint', base it on 'master'. For a bug that's not yet
+ in 'master', find the topic that introduces the regression, and
+ 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',
+ base your work on the tip of that topic.
+
+ - 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
+ to 'next', it's alright to add a note to squash minor corrections
+ 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
+ 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.
+
+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
+commit is the tip of the topic branch.
(1) Make separate commits for logically separate changes.
that starts with '-----BEGIN PGP SIGNED MESSAGE-----'. That is
not a text/plain, it's something else.
-Note that your maintainer does not necessarily read everything
-on the git mailing list. If your patch is for discussion first,
-send it "To:" the mailing list, and optionally "cc:" him. If it
-is trivially correct or after the list reached a consensus, send
-it "To:" the maintainer and optionally "cc:" the list for
-inclusion.
-
-Also note that your maintainer does not actively involve himself in
-maintaining what are in contrib/ hierarchy. When you send fixes and
-enhancements to them, do not forget to "cc: " the person who primarily
-worked on that hierarchy in contrib/.
+Unless your patch is a very trivial and an obviously correct one,
+first send it with "To:" set to the mailing list, with "cc:" listing
+people who are involved in the area you are touching (the output from
+"git blame $path" and "git shortlog --no-merges $path" would help to
+identify them), to solicit comments and reviews. After the list
+reached a consensus that it is a good idea to apply the patch, re-send
+it with "To:" set to the maintainer and optionally "cc:" the list for
+inclusion. Do not forget to add trailers such as "Acked-by:",
+"Reviewed-by:" and "Tested-by:" after your "Signed-off-by:" line as
+necessary.
(4) Sign your work
GMail does not appear to have any way to turn off line wrapping in the web
interface, so this will mangle any emails that you send. You can however
- use "git send e-mail" and send your patches through the GMail SMTP server, or
+ use "git send-email" and send your patches through the GMail SMTP server, or
use any IMAP email client to connect to the google IMAP server and forward
the emails through that.
error (enabled by default).
* `indent-with-non-tab` treats a line that is indented with 8 or more
space characters as an error (not enabled by default).
+* `tab-in-indent` treats a tab character in the initial indent part of
+ the line as an error (not enabled by default).
* `blank-at-eof` treats blank lines added at the end of file as an error
(enabled by default).
* `trailing-space` is a short-hand to cover both `blank-at-eol` and
unreachable objects immediately.
gc.reflogexpire::
+gc.<pattern>.reflogexpire::
'git reflog expire' removes reflog entries older than
- this time; defaults to 90 days.
+ this time; defaults to 90 days. With "<pattern>" (e.g.
+ "refs/stash") in the middle the setting applies only to
+ the refs that match the <pattern>.
gc.reflogexpireunreachable::
+gc.<ref>.reflogexpireunreachable::
'git reflog expire' removes reflog entries older than
this time and are not reachable from the current tip;
- defaults to 30 days.
+ defaults to 30 days. With "<pattern>" (e.g. "refs/stash")
+ in the middle, the setting applies only to the refs that
+ match the <pattern>.
gc.rerereresolved::
Records of conflicted merge you resolved earlier are
following alternatives: {relative,local,default,iso,rfc,short}.
See linkgit:git-log[1].
+log.decorate::
+ Print out the ref names of any commits that are shown by the log
+ command. If 'short' is specified, the ref name prefixes 'refs/heads/',
+ 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
+ specified, the full ref name (including prefix) will be printed.
+ This is the same as the log commands '--decorate' option.
+
log.showroot::
If true, the initial commit will be shown as a big creation event.
This is equivalent to a diff against an empty tree.
remote.<name>.tagopt::
Setting this value to \--no-tags disables automatic tag following when
- fetching from remote <name>
+ fetching from remote <name>. Setting it to \--tags will fetch every
+ tag from remote <name>, even if they are not reachable from remote
+ branch heads.
remote.<name>.vcs::
Setting this to a value <vcs> will cause git to interact with
sendemail.suppresscc::
sendemail.suppressfrom::
sendemail.to::
+sendemail.smtpdomain::
sendemail.smtpserver::
sendemail.smtpserverport::
sendemail.smtpuser::
This variable can be overridden with the -u|--untracked-files option
of linkgit:git-status[1] and linkgit:git-commit[1].
+ status.submodulesummary::
+ Defaults to false.
+ If this is set to a non zero number or true (identical to -1 or an
+ unlimited number), the submodule summary will be enabled and a
+ summary of commits for modified submodules will be shown (see
+ --summary-limit option of linkgit:git-submodule[1]).
+
tar.umask::
This variable can be used to restrict the permission bits of
tar archive entries. The default is 0002, which turns off the
projects / git.git / commitdiff