A template is not a message. Rather it is guidance that needs to be edited. 

If the editor doesn't start, or you don't edit the words then it will be 
ignored by git.  

There has been some recent discussions and patches on the main list to see 
about changing the warning messages to make it all clearer, but I'm not sure if 
it has reached release. 

I think you need a different option flag to say that the file is the 
pre-prepared commit message file.

-F <file> 
--file=<file> 
Take the commit message from the given file.



Philip

[sorry for the outlook top post]

  ----- Original Message ----- 
  From: Thomas Ferris Nicolaisen 
  To: git-users@googlegroups.com 
  Sent: Monday, July 09, 2012 9:49 PM
  Subject: [git-users] Re: git commit -t won't let me use other template


  On Monday, July 9, 2012 9:36:04 PM UTC+2, p4872 wrote:

    Hi,

    I want to check in a squashed merge commit (i.e. the result of git merge 
--squash) that had some conflicts, using the 'original' squash-merge message, 
which is in .git/SQUASH_MSG. From the manual page, i get the impression that i 
should use "git commit -t .git/SQUASH_MSG" to get that file (content) as 
template, but when i try, i still get the contents of .git/COMMIT_EDITMSG which 
summarizes the conflicts i had during the merge.

    Of course, i can copy and paste the content i want myself, but i'd like to 
do it the proper way. Did i misunderstand the -t / --template commit option?




  Interesting. I could recreate your problem, and I was a bit surprised too. 


  Looking at the docs of git commit:


  --template=<file> 
  Use the contents of the given file as the initial version of the commit 
message. The editor is invoked and you can make subsequent changes. If a 
message is specified using the -m or -Foptions, this option has no effect. This 
overrides the commit.template configuration variable.





  I think what's happening here is that the git conflict leaves some state 
behind for the next commit, namely a -F .git/MERGE_MSG parameter somewhere, and 
that's why it is overriding your -t parameter. Or perhaps it is just built in 
to Git that the MERGE_MSG should have precedence over any other potential 
message.


  When I think about it, it is important to have the information from both 
files (that is: both conflict and squash information), so strictly speaking 
there isn't anything improper about using one file, and copying over the 
contents of the other.


  That said, the intuitive behavior for me would be in this case for Git to 
include both messages.  You could send the developers a mail on 
g...@vger.kernel.org and ask what they think about it.


  In the mean time, it is possible to work around it by scripting it somehow 
into the prepare-commit-msg hook.

  -- 
  You received this message because you are subscribed to the Google Groups 
"Git for human beings" group.
  To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/trcl2rbj70cJ.
  To post to this group, send email to git-users@googlegroups.com.
  To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
  For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

  No virus found in this message.
  Checked by AVG - www.avg.com
  Version: 2012.0.2195 / Virus Database: 2437/5121 - Release Date: 07/09/12

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to