Message-Id: <200701211946.l0LJkTMV022057@laptop13.inf.utfsm.cl>
To: Junio C Hamano <junkio@cox.net>
cc: git@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Announce] GIT v1.5.0-rc2
In-reply-to: <7v3b6439uh.fsf@assigned-by-dhcp.cox.net>
References: <7v64b04v2e.fsf@assigned-by-dhcp.cox.net> <7v3b6439uh.fsf@assigned-by-dhcp.cox.net>
Comments: In-reply-to Junio C Hamano <junkio@cox.net>
   message dated "Sun, 21 Jan 2007 03:20:06 -0800."
Date: Sun, 21 Jan 2007 16:46:29 -0300
From: "Horst H. von Brand" <vonbrand@inf.utfsm.cl>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4256
Lines: 126

Junio C Hamano <junkio@cox.net> 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
-
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/