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 information...
[ 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

--

The msysgit Windows installer is available at
    http://code.google.com/p/msysgit/downloads
	Steffen

--

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 thre...
[ 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 thre...
[ 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.

--

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

--

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. ;-)

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

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. ;-)

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.
--

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.

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

--