lkml.org 
[lkml]   [2007]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Announce] GIT v1.5.0-rc2
    Date
    From
    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/

    \
     
     \ /
      Last update: 2007-01-21 22:15    [W:3.405 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site