* "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.<name>.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
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.
* git-archive can optionally substitute keywords in files marked with
export-subst attribute.
+ * git-for-each-ref learned %(xxxdate:<dateformat>) 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
--
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
-
<div class="title">Note</div>\r
</td>\r
<td class="content">Most likely, you are not directly using the core\r
-git Plumbing commands, but using Porcelain like Cogito on top\r
-of it. Cogito works a bit differently and you usually do not\r
-have to run <tt>git-update-index</tt> yourself for changed files (you\r
-do tell underlying git about additions and removals via\r
-<tt>cg-add</tt> and <tt>cg-rm</tt> commands). Just before you make a commit\r
-with <tt>cg-commit</tt>, Cogito figures out which files you modified,\r
-and runs <tt>git-update-index</tt> on them for you.</td>\r
+git Plumbing commands, but using Porcelain such as <tt>git-add</tt>, `git-rm'\r
+and `git-commit'.</td>\r
</tr></table>\r
</div>\r
</div>\r
</div></div>\r
<p>and in fact a lot of the common git command combinations can be scripted\r
with the <tt>git xyz</tt> interfaces. You can learn things by just looking\r
-at what the various git scripts do. For example, <tt>git reset</tt> is the\r
-above two lines implemented in <tt>git-reset</tt>, but some things like\r
+at what the various git scripts do. For example, <tt>git reset</tt> used to be\r
+the above two lines implemented in <tt>git-reset</tt>, but some things like\r
<tt>git status</tt> and <tt>git commit</tt> are slightly more complex scripts around\r
the basic git commands.</p>\r
<p>Many (most?) public remote repositories will not contain any of\r
<div class="content">\r
<pre><tt>$ git branch</tt></pre>\r
</div></div>\r
-<p>which is nothing more than a simple script around <tt>ls .git/refs/heads</tt>.\r
-There will be asterisk in front of the branch you are currently on.</p>\r
+<p>which used to be nothing more than a simple script around <tt>ls .git/refs/heads</tt>.\r
+There will be an asterisk in front of the branch you are currently on.</p>\r
<p>Sometimes you may wish to create a new branch _without_ actually\r
checking it out and switching to it. If so, just use the command</p>\r
<div class="listingblock">\r
<tt>master</tt> branch, and the second column for the <tt>mybranch</tt>\r
branch. Three commits are shown along with their log messages.\r
All of them have non blank characters in the first column (<tt>*</tt>\r
-shows an ordinary commit on the current branch, <tt>.</tt> is a merge commit), which\r
+shows an ordinary commit on the current branch, <tt>-</tt> is a merge commit), which\r
means they are now part of the <tt>master</tt> branch. Only the "Some\r
work" commit has the plus <tt>+</tt> character in the second column,\r
because <tt>mybranch</tt> has not been merged to incorporate these\r
<p>There are (confusingly enough) <tt>git-ssh-fetch</tt> and <tt>git-ssh-upload</tt>\r
programs, which are <em>commit walkers</em>; they outlived their\r
usefulness when git Native and SSH transports were introduced,\r
-and not used by <tt>git pull</tt> or <tt>git push</tt> scripts.</p>\r
+and are not used by <tt>git pull</tt> or <tt>git push</tt> scripts.</p>\r
</dd>\r
</dl>\r
<p>Once you fetch from the remote repository, you <tt>merge</tt> that\r
</div></div>\r
<p>The command writes the commit object name of the common ancestor\r
to the standard output, so we captured its output to a variable,\r
-because we will be using it in the next step. BTW, the common\r
+because we will be using it in the next step. By the way, the common\r
ancestor commit is the "New day." commit in this case. You can\r
tell it by:</p>\r
<div class="listingblock">\r
convenient to organize your project with an informal hierarchy\r
of developers. Linux kernel development is run this way. There\r
is a nice illustration (page 17, "Merges to Mainline") in\r
-link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf\r
-[Randy Dunlap's presentation].</p>\r
+<a href="http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf">Randy Dunlap's presentation</a>.</p>\r
<p>It should be stressed that this hierarchy is purely <strong>informal</strong>.\r
There is nothing fundamental in git that enforces the "chain of\r
patch flow" this hierarchy implies. You do not have to pull\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 30-Sep-2007 00:49:46 UTC\r
+Last updated 30-Oct-2007 08:23:11 UTC\r
</div>\r
</div>\r
</body>\r
[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
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.
$ 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
`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
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.
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:
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
providing generally smoother user experience than the "raw" Core GIT\r
itself and indeed many other version control systems.</tt></pre>\r
</div></div>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>Cogito is no longer maintained as most of its functionality\r
+is now in core GIT.</tt></pre>\r
+</div></div>\r
</li>\r
<li>\r
<p>\r
<div class="literalblock">\r
<div class="content">\r
<pre><tt>Stacked GIT provides a quilt-like patch management functionality in the\r
- GIT environment. You can easily manage your patches in the scope of GIT\r
+GIT environment. You can easily manage your patches in the scope of GIT\r
until they get merged upstream.</tt></pre>\r
</div></div>\r
</li>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:10:09 UTC\r
+Last updated 30-Oct-2007 08:23:11 UTC\r
</div>\r
</div>\r
</body>\r
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/)
- *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.
projects / git.git / commitdiff