Junio C Hamano <junkio@xxxxxxx> 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 git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html