diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/.gitignore | 1 | ||||
| -rw-r--r-- | Documentation/Makefile | 17 | ||||
| -rw-r--r-- | Documentation/RelNotes-1.6.5.4.txt | 32 | ||||
| -rw-r--r-- | Documentation/RelNotes-1.6.5.5.txt | 49 | ||||
| -rw-r--r-- | Documentation/config.txt | 18 | ||||
| -rw-r--r-- | Documentation/git-archive.txt | 5 | ||||
| -rw-r--r-- | Documentation/git-remote.txt | 7 | ||||
| -rw-r--r-- | Documentation/git.txt | 4 | ||||
| -rw-r--r-- | Documentation/gitworkflows.txt | 115 | ||||
| -rw-r--r-- | Documentation/manpage-base-url.xsl.in | 10 | ||||
| -rw-r--r-- | Documentation/user-manual.txt | 20 |
11 files changed, 264 insertions, 14 deletions
diff --git a/Documentation/.gitignore b/Documentation/.gitignore index d8edd90406..1c3a9fead5 100644 --- a/Documentation/.gitignore +++ b/Documentation/.gitignore @@ -8,3 +8,4 @@ gitman.info howto-index.txt doc.dep cmds-*.txt +manpage-base-url.xsl diff --git a/Documentation/Makefile b/Documentation/Makefile index cd5b4396db..037220f544 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -103,6 +103,17 @@ ifdef DOCBOOK_SUPPRESS_SP XMLTO_EXTRA += -m manpage-suppress-sp.xsl endif +# Newer DocBook stylesheet emits warning cruft in the output when +# this is not set, and if set it shows an absolute link. Older +# stylesheets simply ignore this parameter. +# +# Distros may want to use MAN_BASE_URL=file:///path/to/git/docs/ +# or similar. +ifndef MAN_BASE_URL +MAN_BASE_URL = file://$(htmldir)/ +endif +XMLTO_EXTRA += -m manpage-base-url.xsl + # If your target system uses GNU groff, it may try to render # apostrophes as a "pretty" apostrophe using unicode. This breaks # cut&paste, so you should set GNU_ROFF to force them to be ASCII @@ -230,6 +241,7 @@ clean: $(RM) howto-index.txt howto/*.html doc.dep $(RM) technical/api-*.html technical/api-index.txt $(RM) $(cmds_txt) *.made + $(RM) manpage-base-url.xsl $(MAN_HTML): %.html : %.txt $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ @@ -237,7 +249,10 @@ $(MAN_HTML): %.html : %.txt $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ mv $@+ $@ -%.1 %.5 %.7 : %.xml +manpage-base-url.xsl: manpage-base-url.xsl.in + sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@ + +%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(QUIET_XMLTO)$(RM) $@ && \ xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $< diff --git a/Documentation/RelNotes-1.6.5.4.txt b/Documentation/RelNotes-1.6.5.4.txt new file mode 100644 index 0000000000..e42f8b2397 --- /dev/null +++ b/Documentation/RelNotes-1.6.5.4.txt @@ -0,0 +1,32 @@ +Git v1.6.5.4 Release Notes +========================== + +Fixes since v1.6.5.3 +-------------------- + + * "git help" (without argument) used to check if you are in a directory + under git control. There was no breakage in behaviour per-se, but this + was unnecessary. + + * "git prune-packed" gave progress output even when its standard error is + not connected to a terminal; this caused cron jobs that run it to + produce crufts. + + * "git pack-objects --all-progress" is an option to ask progress output + from write-object phase _if_ progress output were to be produced, and + shouldn't have forced the progress output. + + * "git apply -p<n> --directory=<elsewhere>" did not work well for a + non-default value of n. + + * "git merge foo HEAD" was misparsed as an old-style invocation of the + command and produced a confusing error message. As it does not specify + any other branch to merge, it shouldn't be mistaken as such. We will + remove the old style "git merge <message> HEAD <commit>..." syntax in + future versions, but not in this release, + + * "git merge -m <message> <branch>..." added the standard merge message + on its own after user-supplied message, which should have overrided the + standard one. + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.5.5.txt b/Documentation/RelNotes-1.6.5.5.txt new file mode 100644 index 0000000000..ecfc57d875 --- /dev/null +++ b/Documentation/RelNotes-1.6.5.5.txt @@ -0,0 +1,49 @@ +Git v1.6.5.5 Release Notes +========================== + +Fixes since v1.6.5.4 +-------------------- + + * Manual pages can be formatted with older xmlto again. + + * GREP_OPTIONS exported from user's environment could have broken + our scripted commands. + + * In configuration files, a few variables that name paths can begin with + ~/ and ~username/ and they are expanded as expected. This is not a + bugfix but 1.6.6 will have this and without backporting users cannot + easily use the same ~/.gitconfig across versions. + + * "git diff -B -M" did the same computation to hash lines of contents + twice, and held onto memory after it has used the data in it + unnecessarily before it freed. + + * "git diff -B" and "git diff --dirstat" was not counting newly added + contents correctly. + + * "git format-patch revisions... -- path" issued an incorrect error + message that suggested to use "--" on the command line when path + does not exist in the current work tree (it is a separate matter if + it makes sense to limit format-patch with pathspecs like that + without using the --full-diff option). + + * "git grep -F -i StRiNg" did not work as expected. + + * Enumeration of available merge strategies iterated over the list of + commands in a wrong way, sometimes producing an incorrect result. + + * "git shortlog" did not honor the "encoding" header embedded in the + commit object like "git log" did. + + * Reading progress messages that come from the remote side while running + "git pull" is given precedence over reading the actual pack data to + prevent garbled progress message on the user's terminal. + + * "git rebase" got confused when the log message began with certain + strings that looked like Subject:, Date: or From: header. + + * "git reset" accidentally run in .git/ directory checked out the + work tree contents in there. + + +Other minor documentation updates are included. diff --git a/Documentation/config.txt b/Documentation/config.txt index d1e2120e15..35e26972e9 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -126,6 +126,10 @@ advice.*:: Directions on how to stage/unstage/add shown in the output of linkgit:git-status[1] and the template shown when writing commit messages. Default: true. + commitBeforeMerge:: + Advice shown when linkgit:git-merge[1] refuses to + merge to avoid overwritting local changes. + Default: true. -- core.fileMode:: @@ -169,9 +173,10 @@ core.autocrlf:: writing to the filesystem. The variable can be set to 'input', in which case the conversion happens only while reading from the filesystem but files are written out with - `LF` at the end of lines. Currently, which paths to consider - "text" (i.e. be subjected to the autocrlf mechanism) is - decided purely based on the contents. + `LF` at the end of lines. A file is considered + "text" (i.e. be subjected to the autocrlf mechanism) based on + the file's `crlf` attribute, or if `crlf` is unspecified, + based on the file's contents. See linkgit:gitattributes[5]. core.safecrlf:: If true, makes git check if converting `CRLF` as controlled by @@ -380,8 +385,9 @@ Common unit suffixes of 'k', 'm', or 'g' are supported. core.excludesfile:: In addition to '.gitignore' (per-directory) and '.git/info/exclude', git looks into this file for patterns - of files which are not meant to be tracked. See - linkgit:gitignore[5]. + of files which are not meant to be tracked. "{tilde}/" is expanded + to the value of `$HOME` and "{tilde}user/" to the specified user's + home directory. See linkgit:gitignore[5]. core.editor:: Commands such as `commit` and `tag` that lets you edit @@ -670,6 +676,8 @@ color.ui:: commit.template:: Specify a file to use as the template for new commit messages. + "{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the + specified user's home directory. diff.autorefreshindex:: When using 'git-diff' to compare with work tree diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index 3d1c1e75b7..e57979198b 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -74,8 +74,9 @@ OPTIONS The tree or commit to produce an archive for. path:: - If one or more paths are specified, include only these in the - archive, otherwise include all files and subdirectories. + Without an optional path parameter, all files and subdirectories + of the current working directory are included in the archive. + If one or more paths are specified, only these are included. BACKEND EXTRA OPTIONS --------------------- diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 82a3d29673..c272c92d4b 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -13,10 +13,10 @@ SYNOPSIS 'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url> 'git remote rename' <old> <new> 'git remote rm' <name> -'git remote set-head' <name> [-a | -d | <branch>] -'git remote show' [-n] <name> +'git remote set-head' <name> (-a | -d | <branch>) +'git remote' [-v | --verbose] 'show' [-n] <name> 'git remote prune' [-n | --dry-run] <name> -'git remote update' [-p | --prune] [group | remote]... +'git remote' [-v | --verbose] 'update' [-p | --prune] [group | remote]... DESCRIPTION ----------- @@ -30,6 +30,7 @@ OPTIONS -v:: --verbose:: Be a little more verbose and show remote url after name. + NOTE: This must be placed between `remote` and `subcommand`. COMMANDS diff --git a/Documentation/git.txt b/Documentation/git.txt index 5084d27a25..8e93d35e44 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -43,9 +43,11 @@ unreleased) version of git, that is available from 'master' branch of the `git.git` repository. Documentation for older releases are available here: -* link:v1.6.5.3/git.html[documentation for release 1.6.5.3] +* link:v1.6.5.5/git.html[documentation for release 1.6.5.5] * release notes for + link:RelNotes-1.6.5.5.txt[1.6.5.5], + link:RelNotes-1.6.5.4.txt[1.6.5.4], link:RelNotes-1.6.5.3.txt[1.6.5.3], link:RelNotes-1.6.5.2.txt[1.6.5.2], link:RelNotes-1.6.5.1.txt[1.6.5.1], diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt index 2b021e3c15..91c0eea890 100644 --- a/Documentation/gitworkflows.txt +++ b/Documentation/gitworkflows.txt @@ -209,6 +209,121 @@ chance to see if their in-progress work will be compatible. `git.git` has such an official throw-away integration branch called 'pu'. +Branch management for a release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Assuming you are using the merge approach discussed above, when you +are releasing your project you will need to do some additional branch +management work. + +A feature release is created from the 'master' branch, since 'master' +tracks the commits that should go into the next feature release. + +The 'master' branch is supposed to be a superset of 'maint'. If this +condition does not hold, then 'maint' contains some commits that +are not included on 'master'. The fixes represented by those commits +will therefore not be included in your feature release. + +To verify that 'master' is indeed a superset of 'maint', use git log: + +.Verify 'master' is a superset of 'maint' +[caption="Recipe: "] +===================================== +git log master..maint +===================================== + +This command should not list any commits. Otherwise, check out +'master' and merge 'maint' into it. + +Now you can proceed with the creation of the feature release. Apply a +tag to the tip of 'master' indicating the release version: + +.Release tagging +[caption="Recipe: "] +===================================== +`git tag -s -m "GIT X.Y.Z" vX.Y.Z master` +===================================== + +You need to push the new tag to a public git server (see +"DISTRIBUTED WORKFLOWS" below). This makes the tag available to +others tracking your project. The push could also trigger a +post-update hook to perform release-related items such as building +release tarballs and preformatted documentation pages. + +Similarly, for a maintenance release, 'maint' is tracking the commits +to be released. Therefore, in the steps above simply tag and push +'maint' rather than 'master'. + + +Maintenance branch management after a feature release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After a feature release, you need to manage your maintenance branches. + +First, if you wish to continue to release maintenance fixes for the +feature release made before the recent one, then you must create +another branch to track commits for that previous release. + +To do this, the current maintenance branch is copied to another branch +named with the previous release version number (e.g. maint-X.Y.(Z-1) +where X.Y.Z is the current release). + +.Copy maint +[caption="Recipe: "] +===================================== +`git branch maint-X.Y.(Z-1) maint` +===================================== + +The 'maint' branch should now be fast-forwarded to the newly released +code so that maintenance fixes can be tracked for the current release: + +.Update maint to new release +[caption="Recipe: "] +===================================== +* `git checkout maint` +* `git merge --ff-only master` +===================================== + +If the merge fails because it is not a fast-forward, then it is +possible some fixes on 'maint' were missed in the feature release. +This will not happen if the content of the branches was verified as +described in the previous section. + + +Branch management for next and pu after a feature release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After a feature release, the integration branch 'next' may optionally be +rewound and rebuilt from the tip of 'master' using the surviving +topics on 'next': + +.Rewind and rebuild next +[caption="Recipe: "] +===================================== +* `git checkout next` +* `git reset --hard master` +* `git merge ai/topic_in_next1` +* `git merge ai/topic_in_next2` +* ... +===================================== + +The advantage of doing this is that the history of 'next' will be +clean. For example, some topics merged into 'next' may have initially +looked promising, but were later found to be undesirable or premature. +In such a case, the topic is reverted out of 'next' but the fact +remains in the history that it was once merged and reverted. By +recreating 'next', you give another incarnation of such topics a clean +slate to retry, and a feature release is a good point in history to do +so. + +If you do this, then you should make a public announcement indicating +that 'next' was rewound and rebuilt. + +The same rewind and rebuild process may be followed for 'pu'. A public +announcement is not necessary since 'pu' is a throw-away branch, as +described above. + + DISTRIBUTED WORKFLOWS --------------------- diff --git a/Documentation/manpage-base-url.xsl.in b/Documentation/manpage-base-url.xsl.in new file mode 100644 index 0000000000..e800904df3 --- /dev/null +++ b/Documentation/manpage-base-url.xsl.in @@ -0,0 +1,10 @@ +<!-- manpage-base-url.xsl: + special settings for manpages rendered from newer docbook --> +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + version="1.0"> + +<!-- set a base URL for relative links --> +<xsl:param name="man.base.url.for.relative.links" + >@@MAN_BASE_URL@@</xsl:param> + +</xsl:stylesheet> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 67ebffa568..c32dd87c8b 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1183,7 +1183,23 @@ $ git merge branchname ------------------------------------------------- merges the development in the branch "branchname" into the current -branch. If there are conflicts--for example, if the same file is +branch. + +A merge is made by combining the changes made in "branchname" and the +changes made up to the latest commit in your current branch since +their histories forked. The work tree is overwritten by the result of +the merge when this combining is done cleanly, or overwritten by a +half-merged results when this combining results in conflicts. +Therefore, if you have uncommitted changes touching the same files as +the ones impacted by the merge, Git will refuse to proceed. Most of +the time, you will want to commit your changes before you can merge, +and if you don't, then linkgit:git-stash[1] can take these changes +away while you're doing the merge, and reapply them afterwards. + +If the changes are independant enough, Git will automatically complete +the merge and commit the result (or reuse an existing commit in case +of <<fast-forwards,fast-forward>>, see below). On the other hand, +if there are conflicts--for example, if the same file is modified in two different ways in the remote branch and the local branch--then you are warned; the output may look something like this: @@ -1679,7 +1695,7 @@ Sharing development with others Getting updates with git pull ----------------------------- -After you clone a repository and make a few changes of your own, you +After you clone a repository and commit a few changes of your own, you may wish to check the original repository for updates and merge them into your own work. |