Re: What's cooking in git.git (topics)

From: Jeff King <peff@peff.net>
Date: Sep 27, 2007, 02:36 UTC
Message-ID: <20070927023633.GA28902@coredump.intra.peff.net>
In-Reply-To: <7vfy11yyxk.fsf@gitster.siamese.dyndns.org>

On Wed, Sep 26, 2007 at 01:05:59PM -0700, Junio C Hamano wrote:

> * jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
>  + diffcore-rename: cache file deltas
> 
> Parked in 'next' for now but is 'master' material.

My tests after this patch show that spanhash_find is responsible for a large portion of the processing time in large renames, so I am going to look into speeding that up.

Show 11 quoted lines

> * lh/merge (Mon Sep 24 00:51:45 2007 +0200) 6 commits
>  + git-merge: add --ff and --no-ff options
>  + git-merge: add support for --commit and --no-squash
>  + git-merge: add support for branch.<name>.mergeoptions
>  + git-merge: refactor option parsing
>  + git-merge: fix faulty SQUASH_MSG
>  + Add test-script for git-merge porcelain
> 
> Comments?  I personally never felt need for --no-ff but the
> series is reasonably clean so I do not see strong objection
> against this series either.

I like it. I know that --no-ff is frowned upon, but I think previous discussions have mentioned workflows where it might be used intelligently. Since the patch is unlikely to break anything for traditional workflows, I think it is a nice way to let people experiment with alternative workflows that use --no-ff. Maybe something interesting will come of it.

-Peff