Re: [PATCH] Automatically line wrap long commit messages.

From: Junio C Hamano <junkio@cox.net>
Date: Jun 1, 2006, 06:37 UTC
Message-ID: <7v3beptm92.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060601033430.GA13485@spearce.org>

Shawn Pearce <spearce@spearce.org> writes:

> Because git-commit currently performs a status update and throws
> that data into the editor buffer.  That takes longer than committing
> from the command line.  Especially if I've just done a git-diff or
> git-status to see what is changed and about to be committed...

Ah, why does it take this many exchanges to extract the true motive behind what people do even in a technical forum like this, I wonder...

So what you want is not multiple -m options nor piping to fmt. What you really want is an option that is the opposite of -v to git-commit that omits the status list ("_could_ commit if you update-index" part -- since "will commit" is something we would need to compute anyway).

> On a project the size of GIT on a Unix system this isn't a big deal;
> on a 9000 file project on Cygwin this difference is significant
> to me.

I suspect you are suffering from lstat() performance. I wonder if "assume unchanged" git help your situation?