Junio C Hamano, Thu, Aug 28, 2008 21:09:35 +0200: > Marcus Griep <marcus@xxxxxxxx> 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. 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. -- To unsubscribe from this list: 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
