[ANNOUNCE] GIT 1.3.1
- From: Junio C Hamano <junkio@xxxxxxx>
- Date: Tue, 25 Apr 2006 01:04:55 -0700
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Prev by Date: Re: [PATCH/RFC] s390: Hypervisor File System
- Next by Date: Re: [patch 1/2] raid6_end_write_request() spinlock fix
- Previous by thread: __FILE__ gets expanded to absolute pathname
- Next by thread: [patch 0/2] kref debugging (retry)
- Index(es):
Relevant Pages
|
