From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: What's in git.git tonight
Date: Sat, 17 Dec 2005 01:37:12 -0800 [thread overview]
Message-ID: <7voe3g12uv.fsf@assigned-by-dhcp.cox.net> (raw)
Since 0.99.9n, there have been a couple of fixes and some
documentation updates. One notable is that we do not allow '?',
'*' and '[' in ref names anymore --- this was done after the
list discussion with Pasky and friends.
Another notable is "We do not like HEAD branch" patch, but I've
been thinking seriously about reverting it and replace its
effect by also reverting the misguided attempt to disambiguate
branch names and tag names. This patch with a commit message
will follow in a separate message; it currently lives in the
proposed updates branch. One positive effect this change brings
is that it fixes a corner case bug/confusion Johannes mentioned
the other day while diagnosing the trouble Len had with his
repository (I do not think the problem has anything to do with
Len's trouble, though). If you have a branch called "dead", and
you also have a tag called "dead", and if your repository has
only one object whose name begins with "dead"
(e.g. "deadbeef1234..."), "git rev-parse --verify dead" would
pick up the "deadbeef1234..." object, not "dead" tag nor "dead"
head. When no such object exists, "git rev-parse --verify dead"
fails, saying "dead" is ambiguous between heads and tags. This
is just confused, and "reverting the misguided disambiguation"
change will make it pick up the "dead" tag in either case. Most
likely I'll have it in "master" after further testing over the
weekend.
One important patch waiting in the proposed updates is to give
an option to git-fetch-pack to keep the downloaded pack without
unpacking it; this was primarily done to help Cogito, but I
haven't heard back about it from Pasky yet. The primary
difference between this and the clone-pack change that is
already in the master branch, from the user's point of view, is
that git-fetch-pack can be efficiently used in an already
populated repository [*1*]. Imagine cloning "master" branch
from linux-2.6 repository of Linus, and then fetching ALL branch
from libata-dev repository of Jeff --- the difference is large
enough that you would want to keep the downloaded stuff packed,
while you do want to take advantage of the fact that you already
have objects from Linus. Currently it saves exploding about a
~800K pack with 1100 objects in it. Although I mentioned we are
supposed to be in deep feature freeze, I feel it is worth to
have this one in 1.0.
[Footnote]
*1* Theoretically we could deprecate git-clone-pack and use
git-fetch-pack exclusively, if we are willing to create refs
matching what the remote has in the wrapper script git-clone.
next reply other threads:[~2005-12-17 9:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-17 9:37 Junio C Hamano [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-11-06 10:00 What's in git.git tonight Junio C Hamano
2005-11-06 10:54 ` Randal L. Schwartz
2005-11-06 11:57 ` Paul Collins
2005-11-06 12:08 ` Randal L. Schwartz
2005-11-06 12:33 ` Randal L. Schwartz
2005-11-06 18:47 ` Junio C Hamano
2005-11-06 21:07 ` Paul Collins
2005-11-06 12:11 ` Marco Roeland
2005-11-06 12:24 ` Randal L. Schwartz
2005-11-06 12:46 ` Johannes Schindelin
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=7voe3g12uv.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).