Junio C Hamano [off-list ref] wrote:

BTW, as the upcoming v1.5.0 release will introduce quite a bit of
surface changes (although at the really core it still is the old
git and old ways should continue to work), I am wondering if it
would help people to try out and find wrinkles before the real
thing for me to cut a tarball and a set of RPM packages.

Comments?

Also, in the same spirit of giving the release an early
exposure, here is the current draft of 1.5.0 release notes.

-- >8 -- cut here -- >8 --

GIT v1.5.0 Release Notes (draft)
================================

Old news
--------

[...]

 - There is a configuration variable core.legacyheaders that
   changes the format of loose objects so that they are more
   efficient to pack and to send out of the repository over git
   native protocol, since v1.4.2.  However, loose objects
   written in the new format cannot be read by git older than
   that version; people fetching from your repository using
   older clients over dumb transports (e.g. http) using older
   versions of git will also be affected.

Huh?

What are possible values of that variable? What happens if it is set/unset?
I'd suppose that if it is set, you get the old format, but that isn't clear.

 - Since v1.4.3, configuration repack.usedeltabaseoffset allows
   packfile to be created in more space efficient format, which
   cannot be read by git older than that version.

Same as above.

The above two are not enabled by default and you explicitly have
to ask for them, because these two features make repositories
unreadable by older versions of git, and in v1.5.0 we still do
not enable them by default for the same reason.  We will change
this default probably 1 year after 1.4.2's release, when it is
reasonable to expect everybody to have new enough version of
git.

I don't see an upgrade path here that doesn't involve keeping cruft "new
feature is on" variables around indefinitely... Why not just a repository
version?

[...]

Updates in v1.5.0 since v1.4.4 series
-------------------------------------

* Index manipulation

[...]

 - git-add without any argument does not add everything
   anymore.  Use 'git-add .' instead.  Also you can add
   otherwise ignored files with an -f option.

I suppose "git add ." works for 'adding everything' only at the top?

 - git-add tries to be more friendly to users by offering an
   interactive mode.

Why not tell about "git add -i"?

[...]

* Detached HEAD

[...]

 - After detaching your HEAD, you can go back to an existing
   branch with usual "git checkout $branch".  Also you can
   start a new branch using "git checkout -b $newbranch".

Where is such a branch rooted?

 - You can even pull from other repositories, make merges and
   commits while your HEAD is detached.  Also you can use "git
   reset" to jump to arbitrary commit.

Does this leave you on that branch, or still in limbo?

   Going back to undetached state by "git checkout $branch" can

s/undetached/attached/

   lose the current stat you arrived in these ways, and "git
   checkout" refuses when the detached HEAD is not pointed by
   any existing ref (an existing branch, a remote tracking
   branch or a tag).  This safety can be overriden with "git
   checkout -f $branch".

What happens if there are changes in the tracked files?

[...]

* Shallow clones

 - There is a partial support for 'shallow' repositories that
   keeps only recent history.  A 'shallow clone' is created by
   specifying how deep that truncated history should be.

A bit of detail on how to specify shallowness would be nice here...


Very nice work, thanks!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513