From: Junio C Hamano Date: Thu, 01 Jun 2006 06:37:13 GMT Subject: Re: [PATCH] Automatically line wrap long commit messages. Message-ID: <7v3beptm92.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20060601033430.GA13485@spearce.org> Shawn Pearce 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?