The latest feature release GIT 1.5.6 is available at the usual
places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.6.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.6.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.6.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.5.6-1.$arch.rpm	(RPM)

As promised, this cycle was short and the release is with only relatively
small impact changes.

----------------------------------------------------------------
GIT v1.5.6 Release Notes
========================

Updates since v1.5.5
--------------------

(subsystems)

* Comes with updated gitk and git-gui.

(portability)

* git will build on AIX better than before now.

* core.ignorecase configuration variable can be used to work better on
  filesystems that are not case sensitive.

* "git init" now autodetects the case sensitivity of the filesystem and
  sets core.ignorecase accordingly.

* cpio is no longer used; neither "curl" binary (libcurl is still used).

(documentation)

* Many freestanding documentation pages have been converted and made
  available to "git help" (aka "man git<something>") as section 7 of
  the manual pages. This means bookmarks to some HTML documentation
  files may need to be updated (eg "tutorial.html" became
  "gittutorial.html").

(performance)

* "git clone" was rewritten in C.  This will hopefully help cloning a
  repository with insane number of refs.

* "git rebase --onto $there $from $branch" used to switch to the tip of
  $branch only to immediately reset back to $from, smudging work tree
  files unnecessarily.  This has been optimized.

* Object creation codepath in "git-svn" has been optimized by enhancing
  plumbing commands git-cat-file and git-hash-object.

(usability, bells and whistles)

* "git add -p" (and the "patch" subcommand of "git add -i") can choose to
  apply (or not apply) mode changes independently from contents changes.

* "git bisect help" gives longer and more helpful usage ...
[ message continues ]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are ...
[ message continues ]

Following the new tradition we began a few releases ago, I'll rewind the
tip of 'next' shortly.  Two topics will be kicked back to 'pu' while we
are at it (jc/send-pack-tell-me-more and js/rebase-i-sequencer).

This is just an advance warning.
--

[ message continues ]

I wonder why the bugfix commit

	aec7e9cd	Don't append default merge message to -m message

has disappeared or why/if this belongs to js/rebase-i-sequencer.

I noticed this because a test case of sequencer failed during rebasing
to pure "master"/"next" without js/rebase-i-sequencer.


I also have a question:
my development branch for the sequencer prototype is based on next,
then:
	* Merge js/rebase-i-sequencer
	* ... development ...

The only reason that makes js/rebase-i-sequencer important (besides
aec7e9cd which is mentioned above), is for the last patch
("Migrate rebase-i to use sequencer") in the patchset that I want to
send to the list.  (Otherwise a lot of work of Joerg Sommer would be
annotated to me.)
So I wanted to
 1. send a patchset based on "master"/"next" without the rebase-i
    feature extentions of Joerg Sommer, and
 2. resend the last patch (the one about rebase-i) based on "pu",
    where js/rebase-i-sequencer is still merged into.
Is this sane?

(The other variant could be that I send the "Merge js/rebase-i-sequencer"
 commit as a patch to the list, but this sounds insane to me.)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
--

[ message continues ]

On Fri, Jun 27, 2008 at 06:12:20PM +0200, Stephan Beyer <s-beyer@gmx.net> w=

I think it its current form that is not a bugfix. The user may want to
prepend a custom message and may want to replace the original message
with a custom one, and I would not consider either of them as "buggy".

Funny enough, I just sent a patch:

http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=3D86589

that tests the original behaviour. ;-)
[ message continues ]

Hi,

I just looked how you solved that and wanted to start a discussion but

Well, when I do -m <msg>, I expect that my commit message is exactly
<msg>, and not <msg> with appended stuff.
Of course, it doesn't matter what I expect, but I think what the
documentation says matters.
This is (in "master" and in "builtin-merge" of vmiklos.git):

-m <msg>::
	The commit message to be used for the merge commit (in case
	it is created). The `git-fmt-merge-msg` script can be used
	to give a good default for automated `git-merge` invocations.

So it is not mentioned that a standard message is appended, and thus the
original behavior is somehow "buggy" :)

Regards,
  Stephan

--=20
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
[ message continues ]

On Fri, Jun 27, 2008 at 07:19:48PM +0200, Stephan Beyer <s-beyer@gmx.net> w=

Ah, OK. Then the code and the documentation differs and that's a bug,
sure.

=46rom git-merge.sh:

# All the rest are the commits being merged; prepare
# the standard merge summary message to be appended to
# the given message.

I did builtin-merge based on git-merge.sh, not the manpage. ;-)
[ message continues ]

Following git tradition, manpage came after the command's behaviour has
been long established.  It will be a behaviour change, and it is open to
debate if the new behaviour is better or if the proposed change of
behaviour hurts existing users.

--

[ message continues ]

If my opinion counts, I like the current ("prepend") one, and I think
the best would be to add a new option (and/or make it configurable) for
the new ("replace") one.
[ message continues ]

Well, perhaps I am different, but I sometimes have temporary branches
named like "first-silly-experiment" and I do not expect having a
    Merge branch 'another-silly-experiment' into 'first-silly-experiment'
appended, when I do a
    git merge -m "Merge a lot of useful stuff... blabla" another-silly-experiment.

(btw, I don't *really* name my branches like this..it's just an example.)

Well, I see this from a "sequencer author point of view", where
     merge silly-experiment
will invoke an editor,
     merge --standard silly-experiment
generates some kind of the typical standard (or default) message,
and
     merge --message "Merge blabla" silly-experiment
does the "obvious". (For me this is the obvious since I've never
experienced another behavior. All my merges have been using the
now disappeared commit.)

So I'd vote for a "replace" behavior by default on -m, and an 
"append standard message" option, but if there is *one* person
who relies on the prepend feature, I'd also take the "prepend"
default and would like to vote for an option that does the
replacement.

For the current state of the art, it seems that I have to merge
with whatever message and then do a commit -m "..." --amend.

Regards,
  Stephan Beyer

PS: Currently using webmail. So sorry for any too long lines
or whatever.
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
--

[ message continues ]

Welcome to git community.

This message talks about how git.git is managed, and how you can work
with it.

* IRC and Mailing list

Many active members of development community hang around on #git
IRC channel on Freenode.  Its log is available at:

        http://colabti.org/irclogger/irclogger_log/git

The development however is primarily done on the git mailing list
(git@vger.kernel.org).  If you have patches, please send them to the
list, following Documentation/SubmittingPatches.

I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use.  But I am obviously not
perfect.  If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.

The list archive is available at a few public sites as well:

        http://news.gmane.org/gmane.comp.version-control.git/
        http://marc.theaimsgroup.com/?l=git
        http://www.spinics.net/lists/git/

and some people seem to prefer to read it over NNTP:

        nntp://news.gmane.org/gmane.comp.version-control.git

When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:

        http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217

as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.

* Repositories, branches and documentation.

My public git.git repository is at:

        git://git.kernel.org/pub/scm/git/git.git/

Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:

        git://repo.or.cz/alt-git.git/

Impatient people might have better luck with the latter one.

Their gitweb interfaces are found at:

        http://git.kernel.org/?p=git/git.git
        http://repo.or.cz/w/alt-git.git

There are ...
[ message continues ]

The msysgit Windows installer is available at

    http://code.google.com/p/msysgit/downloads

	Steffen
--

[ message continues ]

The latest maintenance release GIT 1.5.6.1 is available at the
usual places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.6.1.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.6.1.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.6.1.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.5.6.1-1.$arch.rpm	(RPM)

GIT v1.5.6.1 Release Notes
==========================

Fixes since v1.5.6
------------------

* Last minute change broke loose object creation on AIX.

* (performance fix) We used to make $GIT_DIR absolute path early in the
  programs but keeping it relative to the current directory internally
  gives 1-3 per-cent performance boost.

* bash completion knows the new --graph option to git-log family.


* git-diff -c/--cc showed unnecessary "deletion" lines at the context
  boundary.

* git-for-each-ref ignored %(object) and %(type) requests for tag
  objects.

* git-merge usage had a typo.

* Rebuilding of git-svn metainfo database did not take rewriteRoot
  option into account.

* Running "git-rebase --continue/--skip/--abort" before starting a
  rebase gave nonsense error messages.

----------------------------------------------------------------

Changes since v1.5.6 are as follows:

Brandon Casey (2):
      git-merge.sh: fix typo in usage message: sucesses --> succeeds
      t7502-commit.sh: test_must_fail doesn't work with inline environment variables

Dan McGee (1):
      completion: add --graph to log command completion

Dmitry Potapov (1):
      fix update-hook-example to work with packed tag references

Jan Krüger (2):
      Documentation: fix formatting in git-svn
      git-svn: make rebuild respect rewriteRoot option

Jeff King (2):
      for-each-ref: implement missing tag values
      clone: create intermediate directories of destination repo

Junio C Hamano (2):
      diff -c/--cc: do not include uninteresting deletion before leading context
      GIT 1.5.6.1

Linus Torvalds (1):
      Make git_dir a path relative ...
[ message continues ]

The msysgit release is available at

    http://code.google.com/p/msysgit/downloads

Besides GIT 1.5.6.1, the installer also brings an updated
msys-1.0.dll that works on Vista.

	Steffen
--

[ message continues ]