Junio C Hamano <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
