git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [ANNOUNCE] GIT 0.99.9n aka 1.0rc6
Date: Wed, 14 Dec 2005 18:36:40 -0800	[thread overview]
Message-ID: <7v7ja7rsqv.fsf@assigned-by-dhcp.cox.net> (raw)

GIT 0.99.9n aka 1.0rc6 is available at the usual places.

	RPM
		http://kernel.org:/pub/software/scm/git/RPMS/

	Debian
		http://kernel.org:/pub/software/scm/git/debian/

I hate to do this, but I ended up merging some more that changes user
experience.  Two notable non-fixes are:

 - big usage string cleanups (Fredrik).

 - git-am enhancements that made a lot of sense for non mbox
   users (HPA).

So git is still in perpetual state of 1.0rc X-<.

No more big changes from now on will be merged to the "master"
branch, except fixes and documentation enhancements.

Well, patches are always welcome, but non-fixes will have to
stay in the proposed updates branch until Wednesday 2005-12-21,
which is the date I am aiming the final 1.0 for.

Right now, I have two somewhat debatable patch in the proposed
updates branch:

 - when merging a branch that renames A->B and another branch
   that renames A->C, merge-recursive leaves B and C in stage 2
   and stage 3, instead of registering them at stage 0 as the
   current "master" branch does.

 - diff gets --abbrev option to shorten the blob object names in
   diff-raw and commit object names in diff-tree headers.

These will *not* be in 1.0 final, unless somebody really wants
them and jumps up-and-down.

I personally feel the "renaming merge" desirable if it works
correctly, but (1) it is a rare case anyway, (2) I have not
tested it extensively, and (3) having hacked it myself, I do not
think I will be able to spot bugs that involve cases I have not
thought about.  So maybe a good test script and an Ack or two
could push me into moving it forward but otherwise it is slated
post 1.0.

The "diff --abbrev" addition is lower impact and I find it
somewhat cute and especially useful while working on an
80-column terminal, but I'd like to make it find unambiguous
prefix, which it does not do currently, before pushing it out.

I am also holding off another one that changes things to use
textual symref for .git/HEAD everywhere, but I think it is well
known that that change is eventually coming sometime after 1.0.

-- >8 -- shortlog -- >8 --
Amos Waterland:
      git rebase loses author name/email if given bad email address

Fredrik Kuivinen:
      Usage message clean-up, take #2
      Trivial usage string clean-up
      git-verify-tag: Usage string clean-up, emit usage string at incorrect invocation
      git-revert: Usage string clean-up
      git-am: Usage string clean-up
      git-applypatch: Usage string clean-up, emit usage string at incorrect invocation
      git-cherry: Usage string clean-up, use the 'usage' function
      git-fetch: Usage string clean-up, emit usage string at unrecognized option
      git-lost-found: Usage string clean-up, emit usage string at incorrect invocation
      git-prune: Usage string clean-up, use the 'usage' function
      git-rebase: Usage string clean-up, emit usage string at incorrect invocation
      git-repack: Usage string clean-up, emit usage at incorrect invocation

H. Peter Anvin:
      git-am support for naked email messages (take 2)

Junio C Hamano:
      diffcore-break.c: check diff_delta() return value.
      Add deltifier test.
      diff-delta.c: allow delta with empty blob.
      Everyday: some examples.
      Revert "diff-delta.c: allow delta with empty blob."
      Revert "Add deltifier test."
      diffcore-break: do not break too small filepair.
      Everyday: a bit more example.
      Documentation: more examples.
      Documentation: fix missing links to git(7)
      Documentation: diff examples.
      Documentation: not learning core git commands.
      git-clone: tell the user a bit more about clone-pack failure.
      allow merging any committish
      checkout-index: fix checking out specific path.
      Everyday: a bit more examples.
      t3200: branch --help does not die anymore.
      applypatch: no need to do non-portable [[ ... ]]
      Documentation: topic branches
      rebase: do not get confused in fast-forward situation.
      Do not let errors pass by unnoticed when running `make check'.
      mailinfo and git-am: allow "John Doe <johndoe>"

Lukas Sandström:
      Bugfixes for git-rebase

Martin Atukunda:
      define MAXPATHLEN for hosts that don't support it

Petr Baudis:
      Make git-send-pack exit with error when some refs couldn't be pushed out

             reply	other threads:[~2005-12-15  2:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-15  2:36 Junio C Hamano [this message]
2005-12-21 12:35 ` [ANNOUNCE] GIT 0.99.9n aka 1.0rc6 Olaf Hering

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=7v7ja7rsqv.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).