From: Junio C Hamano Date: Tue, 1 Jun 2010 01:14:23 +0000 (-0700) Subject: Merge branch 'maint' X-Git-Tag: v1.7.2-rc0~99 X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/225c93a3cac93e8c619e5c8af47d2a781eedcacd?ds=inline;hp=-c Merge branch 'maint' * maint: Documentation/SubmittingPatches: Fix typo in GMail section Documentation/config: describe status.submodulesummary --- 225c93a3cac93e8c619e5c8af47d2a781eedcacd diff --combined Documentation/SubmittingPatches index b9204c77d3,84248daa58..eb53e0636e --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@@ -54,34 -54,6 +54,34 @@@ But the patch submission requirements a 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. @@@ -199,16 -171,17 +199,16 @@@ patch, format it as "multipart/signed" 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 @@@ -547,7 -520,7 +547,7 @@@ Gmai 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. diff --combined Documentation/config.txt index 87f397ed96,bcf3705759..85f763c4d0 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@@ -481,8 -481,6 +481,8 @@@ core.whitespace: 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 @@@ -946,19 -944,13 +946,19 @@@ gc.pruneexpire: unreachable objects immediately. gc.reflogexpire:: +gc..reflogexpire:: 'git reflog expire' removes reflog entries older than - this time; defaults to 90 days. + this time; defaults to 90 days. With "" (e.g. + "refs/stash") in the middle the setting applies only to + the refs that match the . gc.reflogexpireunreachable:: +gc..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 "" (e.g. "refs/stash") + in the middle, the setting applies only to the refs that + match the . gc.rerereresolved:: Records of conflicted merge you resolved earlier are @@@ -1276,13 -1268,6 +1276,13 @@@ log.date: 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. @@@ -1593,9 -1578,7 +1593,9 @@@ remote..uploadpack: remote..tagopt:: Setting this value to \--no-tags disables automatic tag following when - fetching from remote + fetching from remote . Setting it to \--tags will fetch every + tag from remote , even if they are not reachable from remote + branch heads. remote..vcs:: Setting this to a value will cause git to interact with @@@ -1659,7 -1642,6 +1659,7 @@@ sendemail.smtppass: sendemail.suppresscc:: sendemail.suppressfrom:: sendemail.to:: +sendemail.smtpdomain:: sendemail.smtpserver:: sendemail.smtpserverport:: sendemail.smtpuser:: @@@ -1699,6 -1681,13 +1699,13 @@@ If this variable is not specified, it d 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