[ANNOUNCE] GIT 1.3.1

[Junio C Hamano <junkio@cox.net>]

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

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

	git-1.3.1.tar.{gz,bz2}			(tarball)
	RPMS/$arch/git-*-1.3.1-1.$arch.rpm	(RPM)

Just to let people who are new to the game know, 1.3.X (1<=X)
series is purely bugfix maintenance on top of 1.3.0 release, and
no new features will be added unless there is a compelling
reason (think of them like 2.6.16.X releases of the kernel,
slightly looser updates criteria).

There are four primary branches in git.git repository.

 * Releases in the 1.3.X series come from the "maint" branch, which
   was forked at 1.3.0.

 * All the new features and improvements start their life as
   topic branches that are merged to the "pu" (proposed updates)
   branch.  They are often incomplete and/or unstable.  You can
   think of "pu" as the -mm.

 * When these topic branches become stable enough, they are
   merged into "next" branch.  I personally run "next" branch
   for my work to trust my data to it, until very close to the
   next feature release.

 * After being cooked for a few days to a week in "next", these
   good changes graduate to the "master" branch.  Some of them
   die while being cooked there, but that does not happen very
   often (bad apples are culled while in "pu").

I make feature release out of "master" branch periodically,
which are tagged as X.Y.0 releases.  At that point, "maint"
branch is forked to prepare X.Y.1 and onward.

If you are an end user, the "maint" releases are the recommended
stale releases, but you could miss out new features quickly.
Please do send in bug reports for them, but do not expect new
cool features to appear there.

If you want to stay current and stable, I would recommend to
track "master".

If you are a git developer, being aware of what is happening in
"next" would often be very helpful.  The infrastructure you plan
to base your change on may be in the process of being updated
and your changes to "master" can become useless when that
happens.

If you are a truly devoted git hacker, picking what is in "pu"
can be exciting and useful from time to time.

Post 1.3.0 "master" branch development currently contains major
rewrite of log/show/whatchanged infrastructure, and will be
getting updated pack-objects, faster write-tree, consolidated
"git diff" that is not a shell script, and hopefully many
others.  To reiterate, they will be part of 1.4.0 and no 1.3.X
series release will have them.

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

Changes since v1.3.0 are as follows:

Jonas Fonseca:
      Fix filename scaling for binary files

Junio C Hamano:
      git-merge: a bit more readable user guidance.
      pre-commit hook: complain about conflict markers.
      git-commit --amend: two fixes.
      pack-objects: do not stop at object that is "too small"
      mailinfo: decode underscore used in "Q" encoding properly.

Linus Torvalds:
      git-log produces no output

Nicolas Pitre:
      fix pack-object buffer size

Paul Mackerras:
      rev-parse: better error message for ambiguous arguments

Petr Baudis:
      Document git-var -l listing also configuration variables
      Document the configuration file

Santi Béjar:
      Reintroduce svn pools to solve the memory leak.

Serge E. Hallyn:
      socksetup: don't return on set_reuse_addr() error

Shawn Pearce:
      Document git-clone --reference


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/