8

I use Git on the command line. I often develop new features in git branches which are named after the Jira issues (Wikipedia: JIRA) related to them, e.g. branch "new-123" for Jira ticket "NEW-123".

I have a local git prepare-commit-msg hook which will create the commit message by fetching the subject of the Jira ticket from Jira. E.g. "Finished #NEW-123: Cool new feature".

However, I prefer to commit straight from the command line:

git commit -m "Finished #NEW-123: Cool new feature".

I would like to create the quoted commit message merely by pressing [TAB].

I know the bash completion mechanism (Bash: An Introduction to Programmable Completion). But how to use it together with existing command completion (git has otherwise excellent completion in bash)? Can I "chain" the completion?

Or do I need to reprogram the git completion functions (perhaps by adding a hook to my custom function)?

Mikko Koivunalho
  • 331
  • 2
  • 14
  • 4
    Take more personal care on the commit messages. Not everything should be automated. If you automate them that way the history looks ugly. Instead I would write a personal message an add a link to JIRA manually. Also note that texts, titles and headlines in JIRA can be edited after the commit messages has been made. What if a bug arises in code you did for a ticket. Will you open a new ticket for the bugfix or extend or even edit the ticket? (both would be possible, sure) – hek2mgl Apr 18 '15 at 10:16
  • Another thing, I usually do many commits on a feature branch and rebase them before I merge them into master. The result is often a single commit which adds a feature, but it can be also two or more commits if this makes sense. IMHO It makes sense when every commit is a self-containing patch. – hek2mgl Apr 18 '15 at 10:26
  • 1
    I second @hek2mgl; I don't feel like automating commit messages is a good practice. You should always describe the changes in your code in the commit message, along with warnings, comments and explanations of your changes in the commit message body (no the headline). You can always link to the issue in the body to keep a connection between the changes and the feature request/bug discussion, etc. – Fuad Saud Apr 24 '15 at 03:37
  • 1
    I have implemented this before, but instead of tab completing I created a `commit-msg` hook that would look to see if the ticket number was already inserted, and if not, it would insert it. – onionjake Jun 11 '15 at 15:36
  • note that if you don't _ever_ need to edit the message, you can just do `git config --add core.editor true`. note that in that in that case you may want to define e.g. `git config --add alias.tagc 'tag -c core.editor $EDITOR'` or, even better, a shell alias. – strugee Jun 18 '15 at 20:54

1 Answers1

0

You could have a wrapper script, and then write your bash autocompletion for that. Then on the command line you'd be using e.g. git-commit or commit as your command instead of git commit, and you would be in complete control of the autocompletion. (I already have commit as an alias for git commit because I do it so much.)

I agree with all the comments above though, if you were doing this in my team I'd be disappointed; you should be spending time on your commit logs and putting some detail in there, not trying to bang them out in one line. But that's up to you.

Ewan Mellor
  • 6,747
  • 1
  • 24
  • 39