From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: What's in master and pu (aka when will 1.0rc4 be out)
Date: Sun, 27 Nov 2005 02:56:21 -0800 [thread overview]
Message-ID: <7vek52e4ve.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <7voe48gqg9.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Fri, 25 Nov 2005 17:15:02 -0800")
Junio C Hamano <junkio@cox.net> writes:
> This series is what I've been cooking for the past several days,
> partly based on patch from Martin Atukunda but with hopefully
> smaller impact.
>
> [PATCH 1/4] Repository format version check.
> [PATCH 2/4] Check repository format version in enter_repo().
> [PATCH 3/4] init-db: check template and repository format.
> [PATCH 4/4] setup_git_directory(): check repository format version.
And they are now in the master branch, along with a couple of
bugfixes I received in the last couple of days. I've given them
some testing and believe they are in good enough shape for 1.0
futureproofing. Bug reports with reproduction recipe and/or
patch are most welcomed.
Cooking in the proposed updates branch is the 8-series "work
from subdirectory" patch I posted yesterday, with some polishing
based on suggestion from Linus. The ls-tree rework is not
included at this point, neither is the git-sh-setup, both of
which unfortunately have wider impact than I feel comfortable to
swallow in one day.
I am hoping to base the next "maint" branch update, probably on
Wednesday, on what is in "pu" tonight, with safer updates I will
receive from the list (Documentation fixes and updates, and
archimport updates from Eric and Martin are the candidates).
That will be tagged as 1.0rc4 and hopefully be the last 1.0rc,
which means no more major feature/semantics changes after that
until 1.0 --- famous last words.
So I anticipate that many of the barebone Porcelain commands
that insist on running from the toplevel will ship the way they
are in 1.0. If you run "git grep git-sh-setup 'git*sh'", you
will notice that most of them are whole-tree operations anyway,
so not much is lost [*1*].
[Footnote]
*1* Bisecting only in a subdirectory might be an interesting
thing to do, hunting down a bug in a subsystem, but usually a
subsystem has at least two relevant subdirectories (source and
include file trees) ;-).
I suspect that it would be trivial to convert whole-repository
operations such as count-objects, prune, and repack to work from
subdirectory, although the value of that is dubious.
next prev parent reply other threads:[~2005-11-27 10:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-26 1:15 [PATCH 0/4] Repository format version check series Junio C Hamano
2005-11-27 10:56 ` Junio C Hamano [this message]
2005-11-27 13:11 ` What's in master and pu (aka when will 1.0rc4 be out) Timo Hirvonen
2005-11-27 19:32 ` Linus Torvalds
2005-11-27 21:08 ` Junio C Hamano
2005-11-28 1:51 ` [PATCH] bisect: quote pathnames for eval safety Junio C Hamano
2005-11-28 2:12 ` Junio C Hamano
2005-11-29 6:42 ` [PATCH 0/4] Repository format version check series Martin Atukunda
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=7vek52e4ve.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@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).