Marcus Griep [off-list ref] writes:
Currently, using any editor to edit a commit message for 'git commit'
kicks of a 'git status' which is then included as comments to give
the commit author some context. However, in some situations, such as
having a working tree of many hundred thousand files or on an inefficient
filesystem,
I am not interested in this particular patch, especially the part that
hoards a short-and-nice -S flag that we could use for something more
useful. Also calling the configuration variable "nostatus" is backwards;
I'd name it to "showstatus" that defaults to "true" if I were doing this.
You did not mention exactly how the "hundred thousand files on an
inefficient filesystem" is a problem, but if it is about listing untracked
files, I thought Marius Storm-Olsen added a feature to address that with
4bfee30 (Add an optional <mode> argument to commit/status -u|--untracked-files
option, 2008-06-05).
If that is not still enough for your particular use case, I think you can
have a custom wrapper that does:
#!/bin/sh
: >.log-message-file &&
vi .log-message-file &&
git commit -F .log-message-file "$@" &&
rm -f .log-message-file
without touching git at all.
Junio C Hamano, Thu, Aug 28, 2008 21:09:35 +0200:
Marcus Griep [off-list ref] writes:
quoted
Currently, using any editor to edit a commit message for 'git commit'
kicks of a 'git status' which is then included as comments to give
the commit author some context. However, in some situations, such as
having a working tree of many hundred thousand files or on an inefficient
filesystem,
I am not interested in this particular patch, especially the part that
hoards a short-and-nice -S flag that we could use for something more
useful. Also calling the configuration variable "nostatus" is backwards;
I'd name it to "showstatus" that defaults to "true" if I were doing this.
I like it (almost. I agree, it is not a very good idea to use up "-S"
for such a thing). Not because of "inefficient filesystem" (I have
proper systems at home), but because I more often need no file list in
the commit message than I do need one. It is just annoyance. OTOH,
maybe I'm just too used to put things in the index and trust that. Or
maybe it is again that stupid user-friendliness.
If that is not still enough for your particular use case, I think you can
have a custom wrapper that does:
#!/bin/sh
: >.log-message-file &&
vi .log-message-file &&
git commit -F .log-message-file "$@" &&
rm -f .log-message-file
without touching git at all.
That's not enough. Consider "-mMessage -e", "-t" or "-c" flags of git
commit. The wrapper would have to catch them all! Not to mention the
future flags in the same ballpark.
ATM, I just use that "--cached" (from the patch I mentioned in the
other mail) with "--cleanup=verbatim" to get the commit message just
how I like them.