From fb4fa4ebbe0c116c4dbc060c9d1f3b2f1e84e0bd Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 30 Oct 2007 08:24:24 +0000 Subject: [PATCH] Autogenerated HTML docs for v1.5.3.4-452-g09149 --- RelNotes-1.5.3.5.txt | 21 +++++++++++++++++++++ RelNotes-1.5.4.txt | 28 ++++++++++++++++++++++++++-- core-tutorial.html | 28 +++++++++++----------------- core-tutorial.txt | 26 ++++++++++---------------- git-tools.html | 9 +++++++-- git-tools.txt | 5 ++++- 6 files changed, 79 insertions(+), 38 deletions(-) diff --git a/RelNotes-1.5.3.5.txt b/RelNotes-1.5.3.5.txt index 9581e03c4..e28d92f61 100644 --- a/RelNotes-1.5.3.5.txt +++ b/RelNotes-1.5.3.5.txt @@ -71,3 +71,24 @@ Fixes since v1.5.3.4 * "make clean" no longer deletes the configure script that ships with the git tarball, making multiple architecture builds easier. + + * "git-remote show origin" spewed a warning message from Perl + when no remote is defined for the current branch via + branch..remote configuration settings. + + * Building with NO_PERL_MAKEMAKER excessively rebuilt contents + of perl/ subdirectory by rewriting perl.mak. + + * http.sslVerify configuration settings were not used in scripted + Porcelains. + + * "git-add" leaked a bit of memory while scanning for files to add. + + * A few workarounds to squelch false warnings from recent gcc have + been added. + +-- +exec >/var/tmp/1 +O=v1.5.3.4-55-gf120ae2 +echo O=`git describe refs/heads/maint` +git shortlog --no-merges $O..refs/heads/maint diff --git a/RelNotes-1.5.4.txt b/RelNotes-1.5.4.txt index ceee85723..133fa64d2 100644 --- a/RelNotes-1.5.4.txt +++ b/RelNotes-1.5.4.txt @@ -4,6 +4,8 @@ GIT v1.5.4 Release Notes Updates since v1.5.3 -------------------- + * Comes with much improved gitk. + * git-reset is now built-in. * git-send-email can optionally talk over ssmtp and use SMTP-AUTH. @@ -19,6 +21,29 @@ Updates since v1.5.3 * git-archive can optionally substitute keywords in files marked with export-subst attribute. + * git-for-each-ref learned %(xxxdate:) syntax to + show the various date fields in different formats. + + * git-gc --auto is a low-impact way to automatically run a + variant of git-repack that does not lose unreferenced objects + (read: safer than the usual one) after the user accumulates + too many loose objects. + + * git-push has been rewritten in C. + + * git-push learned --dry-run option to show what would happen + if a push is run. + + * git-remote learned "rm" subcommand. + + * git-rebase --interactive mode can now work on detached HEAD. + + * git-cvsserver can be run via git-shell. + + * git-am and git-rebase are far less verbose. + + * git-pull learned to pass --[no-]ff option to underlying git-merge. + * Various Perforce importer updates. Fixes since v1.5.3 @@ -29,7 +54,6 @@ this release, unless otherwise noted. -- exec >/var/tmp/1 -O=v1.5.3.2-99-ge4b2890 +O=v1.5.3.4-450-g952a9e5 echo O=`git describe refs/heads/master` git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint - diff --git a/core-tutorial.html b/core-tutorial.html index 6b27fbccc..287b76380 100644 --- a/core-tutorial.html +++ b/core-tutorial.html @@ -801,13 +801,8 @@ can explore on your own.

Note
Most likely, you are not directly using the core -git Plumbing commands, but using Porcelain like Cogito on top -of it. Cogito works a bit differently and you usually do not -have to run git-update-index yourself for changed files (you -do tell underlying git about additions and removals via -cg-add and cg-rm commands). Just before you make a commit -with cg-commit, Cogito figures out which files you modified, -and runs git-update-index on them for you. +git Plumbing commands, but using Porcelain such as git-add, `git-rm' +and `git-commit'. @@ -930,8 +925,8 @@ tells you they need to be updated.

and in fact a lot of the common git command combinations can be scripted with the git xyz interfaces. You can learn things by just looking -at what the various git scripts do. For example, git reset is the -above two lines implemented in git-reset, but some things like +at what the various git scripts do. For example, git reset used to be +the above two lines implemented in git-reset, but some things like git status and git commit are slightly more complex scripts around the basic git commands.

Many (most?) public remote repositories will not contain any of @@ -1036,8 +1031,8 @@ you have, you can say

$ git branch
-

which is nothing more than a simple script around ls .git/refs/heads. -There will be asterisk in front of the branch you are currently on.

+

which used to be nothing more than a simple script around ls .git/refs/heads. +There will be an asterisk in front of the branch you are currently on.

Sometimes you may wish to create a new branch _without_ actually checking it out and switching to it. If so, just use the command

@@ -1163,7 +1158,7 @@ the later output lines is used to show commits contained in the master branch, and the second column for the mybranch branch. Three commits are shown along with their log messages. All of them have non blank characters in the first column (* -shows an ordinary commit on the current branch, . is a merge commit), which +shows an ordinary commit on the current branch, - is a merge commit), which means they are now part of the master branch. Only the "Some work" commit has the plus + character in the second column, because mybranch has not been merged to incorporate these @@ -1306,7 +1301,7 @@ to help dumb transport downloaders.

There are (confusingly enough) git-ssh-fetch and git-ssh-upload programs, which are commit walkers; they outlived their usefulness when git Native and SSH transports were introduced, -and not used by git pull or git push scripts.

+and are not used by git pull or git push scripts.

Once you fetch from the remote repository, you merge that @@ -1423,7 +1418,7 @@ The command it uses is git-merge-base:

The command writes the commit object name of the common ancestor to the standard output, so we captured its output to a variable, -because we will be using it in the next step. BTW, the common +because we will be using it in the next step. By the way, the common ancestor commit is the "New day." commit in this case. You can tell it by:

@@ -1689,8 +1684,7 @@ repositories every once in a while.

convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There is a nice illustration (page 17, "Merges to Mainline") in -link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf -[Randy Dunlap's presentation].

+Randy Dunlap's presentation.

It should be stressed that this hierarchy is purely informal. There is nothing fundamental in git that enforces the "chain of patch flow" this hierarchy implies. You do not have to pull @@ -1954,7 +1948,7 @@ to follow, not easier.

diff --git a/core-tutorial.txt b/core-tutorial.txt index 6b2590d07..d8e78ac8f 100644 --- a/core-tutorial.txt +++ b/core-tutorial.txt @@ -553,13 +553,8 @@ can explore on your own. [NOTE] Most likely, you are not directly using the core -git Plumbing commands, but using Porcelain like Cogito on top -of it. Cogito works a bit differently and you usually do not -have to run `git-update-index` yourself for changed files (you -do tell underlying git about additions and removals via -`cg-add` and `cg-rm` commands). Just before you make a commit -with `cg-commit`, Cogito figures out which files you modified, -and runs `git-update-index` on them for you. +git Plumbing commands, but using Porcelain such as `git-add`, `git-rm' +and `git-commit'. Tagging a version @@ -686,8 +681,8 @@ $ git reset and in fact a lot of the common git command combinations can be scripted with the `git xyz` interfaces. You can learn things by just looking -at what the various git scripts do. For example, `git reset` is the -above two lines implemented in `git-reset`, but some things like +at what the various git scripts do. For example, `git reset` used to be +the above two lines implemented in `git-reset`, but some things like `git status` and `git commit` are slightly more complex scripts around the basic git commands. @@ -805,8 +800,8 @@ you have, you can say $ git branch ------------ -which is nothing more than a simple script around `ls .git/refs/heads`. -There will be asterisk in front of the branch you are currently on. +which used to be nothing more than a simple script around `ls .git/refs/heads`. +There will be an asterisk in front of the branch you are currently on. Sometimes you may wish to create a new branch _without_ actually checking it out and switching to it. If so, just use the command @@ -952,7 +947,7 @@ the later output lines is used to show commits contained in the `master` branch, and the second column for the `mybranch` branch. Three commits are shown along with their log messages. All of them have non blank characters in the first column (`*` -shows an ordinary commit on the current branch, `.` is a merge commit), which +shows an ordinary commit on the current branch, `-` is a merge commit), which means they are now part of the `master` branch. Only the "Some work" commit has the plus `+` character in the second column, because `mybranch` has not been merged to incorporate these @@ -1086,7 +1081,7 @@ to help dumb transport downloaders. There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload` programs, which are 'commit walkers'; they outlived their usefulness when git Native and SSH transports were introduced, -and not used by `git pull` or `git push` scripts. +and are not used by `git pull` or `git push` scripts. Once you fetch from the remote repository, you `merge` that with your current branch. @@ -1193,7 +1188,7 @@ $ mb=$(git-merge-base HEAD mybranch) The command writes the commit object name of the common ancestor to the standard output, so we captured its output to a variable, -because we will be using it in the next step. BTW, the common +because we will be using it in the next step. By the way, the common ancestor commit is the "New day." commit in this case. You can tell it by: @@ -1459,8 +1454,7 @@ Although git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There is a nice illustration (page 17, "Merges to Mainline") in -link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf -[Randy Dunlap's presentation]. +link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. It should be stressed that this hierarchy is purely *informal*. There is nothing fundamental in git that enforces the "chain of diff --git a/git-tools.html b/git-tools.html index 38da36c53..0e4bdcb63 100644 --- a/git-tools.html +++ b/git-tools.html @@ -282,6 +282,11 @@ storage system. It aims at seamless user interface and ease of use, providing generally smoother user experience than the "raw" Core GIT itself and indeed many other version control systems. +
+
+
Cogito is no longer maintained as most of its functionality
+is now in core GIT.
+

  • @@ -301,7 +306,7 @@ slightly different feature set. 

    Stacked GIT provides a quilt-like patch management functionality in the
- GIT environment. You can easily manage your patches in the scope of GIT
+GIT environment. You can easily manage your patches in the scope of GIT
 until they get merged upstream.
    • @@ -433,7 +438,7 @@ comprehensive list.

    diff --git a/git-tools.txt b/git-tools.txt index 10653ff89..a96403cb8 100644 --- a/git-tools.txt +++ b/git-tools.txt @@ -22,6 +22,9 @@ Alternative/Augmentative Porcelains providing generally smoother user experience than the "raw" Core GIT itself and indeed many other version control systems. + Cogito is no longer maintained as most of its functionality + is now in core GIT. + - *pg* (http://www.spearce.org/category/projects/scm/pg/) @@ -33,7 +36,7 @@ Alternative/Augmentative Porcelains - *StGit* (http://www.procode.org/stgit/) Stacked GIT provides a quilt-like patch management functionality in the - GIT environment. You can easily manage your patches in the scope of GIT + GIT environment. You can easily manage your patches in the scope of GIT until they get merged upstream. -- 2.26.2