Re: [RFH] An early draft of v1.5.0 release notes

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 27, 2006, 08:18 UTC
Message-ID: <20061227081819.GB23022@spearce.org>
In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.

This is certainly a good idea. And your summary was pretty good too, I enjoyed the read. This group has certainly accomplished quite a bit lately!

Just a few comments:

Show 7 quoted lines

>  - Pack-compatible loose object headers, introduced between
>    v1.4.1 and v1.4.2; repository cannot be read with ancient
>    version of git anymore -- this is a one-way street but
>    core.legacyheaders is still not enabled by default);
> 
>  - delta-base-offset pack encoding, introduced between v1.4.2
>    and v1.4.3; this is also a one-way street.

Perhaps you can clarify that using these means the repository cannot be used with an earlier version of Git? You may also want to highlight why these features are good, answering the question "Why should I enable them if it breaks backwards compatibility?".

Isn't the new packed-refs format also a one-way street?  If you
use them for tags on a web server and the client is using a very
old http commit walker, what happens?

>  - git-clone used to be buggy and copied refs outside refs/heads
>    and refs/tags; it doesn't anymore.

I mentioned to you on #git this morning that I don't think this is noteworthy for this release.

You missed talking about the mess of pack files created by git-push
now, especially with pushes over 100 objects.  ;-)

>  - git-push can now be used to delete a remote branch or a tag.

You should mention this requires server side support too.  I read
that and assumed I could just upgrade my client and push to delete
- which isn't the case, and I know its not...  but I still read it
that way.

>  - "git show-branch" learned showing the reflog data with the
>    new --reflog option.

I had hoped we could get 'git reflog show' into 1.5.0 but the
current discussion with Johannes seems like that's unlikely.

>  - We have been depended on "merge" program from RCS suite for
>    the file-level 3-way merge, but now we lost this dependency.

Perhaps just reword as:

	We no longer require the "merge" program from the RCS suite.
	All 3-way file-level merges are now done internally.

>  - git-shortlog is not in Perl anymore, and more importantly it
>    does not have to be piped output from git-log.  It can
>    traverse the commit ancestry itself.

The "traverse the commit ancestry itself" part is not very readable for the average user. How about instead:

	git-shortlog is no longer a Perl script.  git-shortlog also
	no longer requires output piped from git-log; it can accept
	revision parameters directly on the command line.

-- 
Shawn.