git-commit feature request: pass editor command line options
I'd like to be able to have git-commit pass the commit-message editor command line options which aren't passed to the editor for other usages. Right now I have "co" aliased to "!sh -c 'GIT_EDITOR=git-commit-editor git commit'", where git-commit-editor is a wrapper around my editor-of-choice which passes the editor the command line options I want, but it'd be simpler and cleaner if I could just set "commit.editor_options=-BAR". Or even let there be a separate editor for commits, so I could do "core.editor=foo" and "commit.editor=foo -BAR".
Signature · 2 lines
View this message in context: http://www.nabble.com/git-commit-feature-request%3A-pass-editor-command-line-options-tp25885354p25885354.html Sent from the git mailing list archive at Nabble.com.
Quoted 9 lines · Matthew Cline
I'd like to be able to have git-commit pass the commit-message editor command line options which aren't passed to the editor for other usages. Right now I have "co" aliased to "!sh -c 'GIT_EDITOR=git-commit-editor git commit'", where git-commit-editor is a wrapper around my editor-of-choice which passes the editor the command line options I want, but it'd be simpler and cleaner if I could just set "commit.editor_options=-BAR". Or even let there be a separate editor for commits, so I could do "core.editor=foo" and "commit.editor=foo -BAR".
Hmm, what is the use-case when using an option --foo is useful when creating a commit, but not useful when crating a tag?
Apart from introducing inconsistency...
Quoted 2 lines · Miklos Vajna
Hmm, what is the use-case when using an option --foo is useful when creating a commit, but not useful when crating a tag?
In my case, it's using a commit template which starts with a comment, so I want to move the cursor down to the line below the comment.
Quoted 7 lines · Matthew Cline
Quoted 2 lines · Miklos Vajna
Hmm, what is the use-case when using an option --foo is useful when creating a commit, but not useful when crating a tag?
In my case, it's using a commit template which starts with a comment, so I want to move the cursor down to the line below the comment.
Then rebase, tag, add -e and even commit --amend would use core.editor, while commit alone would use commit.editor, right?
A minor confusion would be that git commit --amend would not use commit.editor. ;-)
Quoted 11 lines · Miklos Vajna
Quoted 9 lines · Matthew Cline
I'd like to be able to have git-commit pass the commit-message editor command line options which aren't passed to the editor for other usages. Right now I have "co" aliased to "!sh -c 'GIT_EDITOR=git-commit-editor git commit'", where git-commit-editor is a wrapper around my editor-of-choice which passes the editor the command line options I want, but it'd be simpler and cleaner if I could just set "commit.editor_options=-BAR". Or even let there be a separate editor for commits, so I could do "core.editor=foo" and "commit.editor=foo -BAR".
Quoted 4 lines
Hmm, what is the use-case when using an option --foo is useful when creating a commit, but not useful when crating a tag?
Apart from introducing inconsistency...
Not between commit and tag, but I can see you may want to auto-wrap for log message but forbid auto-wrap when editing rebase insn sheet during "rebase -i".
Quoted 8 lines · Junio C Hamano
Quoted 4 lines
Hmm, what is the use-case when using an option --foo is useful when creating a commit, but not useful when crating a tag?
Apart from introducing inconsistency...
Not between commit and tag, but I can see you may want to auto-wrap for log message but forbid auto-wrap when editing rebase insn sheet during "rebase -i".
I think most people who want that just have their editor automagically recognize the different situations based on the file name or contents. I don't think the original author is wrong to want to be able to use command-line options to do so, but if he is using a common editor like vim or emacs, I think such autodetection has already been written.
-Peff