Re: [Announce] GIT v1.5.0-rc2
- From
Horst H. von Brand <vonbrand@inf.utfsm.cl>
- Date
- Jan 21, 2007, 19:46 UTC
- Message-ID
- <200701211946.l0LJkTMV022057@laptop13.inf.utfsm.cl>
- In-Reply-To
- <7v3b6439uh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
Show 18 quoted lines
> 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 > --------
[...]
Show 8 quoted lines
> - 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.
Show 7 quoted lines
> 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/
Show 5 quoted lines
> 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?
[...]
Show 5 quoted lines
> * 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