Git development
 help / color / mirror / Atom feed
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