Shawn Pearce <spearce@xxxxxxxxxxx> 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?
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html