From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: What's in git.git (with specific RFHs)
Date: Tue, 21 Feb 2006 03:23:34 -0800 [thread overview]
Message-ID: <7vfymdx8eh.fsf@assigned-by-dhcp.cox.net> (raw)
* The 'master' branch has these since the last announcement.
- more portability bits from Johannes.
I'm holding off Makefile changes because it seems to trigger
"make -j" breakage. Testing, diagnosing and fixing the
version in the 'next' branch by more knowledgeable people is
very much appreciated.
- merge-tree by Linus.
- git-mktree: reverse of git-ls-tree.
I am hoping that this may help a new merge engine based on
merge-tree by Linus, but maybe not. It depends on how you
use merge-tree output.
- loosening "empty ident" errors.
Enough people seem to have been bitten by this since 1.2.0
was released.
- Fix fmt-merge-msg counting.
- cherry-pick/revert: rewording error-help message.
- git-svn updates from Erig Wong (contrib/).
* The 'next' branch, in addition, has these.
- "Assume unchanged git".
I have been using this in production for some time, without
usin CE_VALID, and am reasonably sure this does not break
anything for normal use. I am hoping to push this one to
'master' sometime this week. If people can find missing or
incomplete docs in this part, help is appreciated.
- Solaris 9+ portability bits from Paul Jakma.
Testing by people with Solaris 8 boxes to make sure this does
not regress and/or people with Solaris 9 or 10 boxes to see
if this help is appreciated. Quite likely to be "master"
material without further changes.
- Reusing data from existing packs, and "Thin pack" bandwidth
reduction for "git push" and "git fetch".
I am holding these off not because they are risky (I've been
using them in the production over the long weekend), but I'm
keeping them to entice people to try out the 'next' branch
;-). Quite likely to be "master" material without further
changes.
- Perl 5.6 backward compatibility.
Instead of open($fh, '-|', @list), use a bit older equivalent
form. Thanks for Johannes and Eric Wong. Quite likely to be
"master" material without further changes.
- git-annotate by Ryan and git-blame by Fredrik.
The one by Fredrik, being all in C, doing all git things
internally and forking only diff, seems much faster, but it
seems to have inherited bugs from my original blame script
implementation from long time ago. Ryan's one seems to be
computing sensible results.
* The 'pu' branch, in addition, has these.
- "Bash completion" in Ben Clifford (contrib/)
Without requests from the list, I am not particularly
interested in carrying this in my tree, but I wanted to try
out "an even cooler merge" myself, just like Linus did with
gitk merge.
- "Bound commit" lowlevel machinery for subprojects support.
Honestly, I am not very interested in this myself. If
somebody is interested in gitlink based subproject support,
the parts this touches would interfere with it -- in which
case I'd drop this.
reply other threads:[~2006-02-21 11:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=7vfymdx8eh.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