LKML Archive on
help / color / mirror / Atom feed
From: "Horst H. von Brand" <>
To: Junio C Hamano <>
Subject: Re: [Announce] GIT v1.5.0-rc2
Date: Sun, 21 Jan 2007 16:46:29 -0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Junio C Hamano <> 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.


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


> 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


>    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
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

  parent reply	other threads:[~2007-01-21 20:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-21  8:56 Junio C Hamano
2007-01-21 11:20 ` Junio C Hamano
2007-01-21 13:42   ` Bill Lear
2007-01-21 13:52     ` Bill Lear
2007-01-21 21:26       ` Johannes Schindelin
2007-01-21 21:33         ` Jakub Narebski
2007-01-21 22:01           ` Johannes Schindelin
2007-01-21 22:24             ` Jakub Narebski
2007-01-21 13:43   ` Willy Tarreau
2007-01-21 15:06     ` Jakub Narebski
2007-01-21 18:58     ` Junio C Hamano
2007-01-21 19:49       ` H. Peter Anvin
2007-01-22 17:23         ` Nicolas Pitre
2007-01-21 20:01       ` Horst H. von Brand
2007-01-22  1:27         ` Junio C Hamano
2007-01-21 19:46   ` Horst H. von Brand [this message]
2007-01-21 21:55   ` Johannes Schindelin
2007-01-21 22:45     ` Jakub Narebski
2007-01-22 18:08   ` Carl Worth
2007-01-22 19:28     ` Junio C Hamano
2007-01-23  1:01       ` Carl Worth
2007-01-22 18:22   ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [Announce] GIT v1.5.0-rc2' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).