[BUG] Git won't commit

Hello Everybody,

Hope this is the right place to send this bug report.

It just appeared today, last time I've made a successful commit was 3 days ago. Now every commit, in no matter which repository I have (I've tried old ones, cloned today, github ones etc) fails with the following message.

[master 09-mapas] git commit fatal: could not read 'template': No such file or directory

It happens both with the stock git binary that came with Xcode 4.1 on OSX Lion (1.7.4.4) [/usr/local/bin/git], and the homebrew version (1.7.6) [/usr/bin/git].

I haven't changed much of my system during those days besides installing macports and tinycdb (with ports). Don't see any close relation, both tinycdb and macports were removed.

Curiously, it works well with the git binary that comes with Github.app for mac, whose version is 1.7.4.

-- View this message in context: http://git.661346.n2.nabble.com/BUG-Git-won-t-commit-tp6681082p6681082.html Sent from the git mailing list archive at Nabble.com.

I have installed an stock version of git 1.7.6 from here, and I've got the same problem.

http://code.google.com/p/git-osx-installer/downloads/detail?name=git-1.7.6-x86_64-snow-leopard.dmg&can=3&q=

I've forgot to mention but I've updated all homebrew formulas during this past days too, so it might be that previously I had a homebrew version of git whose version where below or equal 1.4, and that something changed causing this error now.

-- View this message in context: http://git.661346.n2.nabble.com/BUG-Git-won-t-commit-tp6681082p6681098.html Sent from the git mailing list archive at Nabble.com.

On Fri, Aug 12, 2011 at 17:13, Fabricio Nascimento <fabriciosn@gmail.com> wrote:

What does the following output for you?

  git config --get commit.template

2011/8/12 Fabrício Nascimento <fabricio@tailorbirds.com.br>:

Did you get this problem figured out? If not, run:

  git config --unset commit.template

and then try making a commit as usual.

As for why one version works but the other does not, I'm not sure.

Hi,

Michael Witten wrote:

It's my fault, I'm afraid:

 $ git log v1.7.4..v1.7.4.4 --grep=template --no-merges
 commit 2140b140
 Author: Jonathan Nieder <jrnieder@gmail.com>
 Date:   Fri Feb 25 03:07:57 2011 -0600

     commit: error out for missing commit message template

     When "git commit" was rewritten in C (v1.5.4-rc0~78^2~30,
     2007-11-08), a subtle bug in --template was introduced.  If the
     file named by a --template parameter is missing, previously git
     would error out with a message:

         Commit template file does not exist.

     but in the C version the --template parameter gets ignored and
     the default template is used.

     t7500 has two tests for this case which would have caught it, except
     that with the default $EDITOR, the commit message template is left
     unmodified, causing 'git commit' to error out and the test to
     succeed.

     Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
     Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fabricio, do you remember what you were trying to do when the "[commit] template" configuration got set? Currently the error message says

	fatal: could not read '<path>'

where <path> is the configured template filename; probably this should be changed to mention (1) that the file we were expecting to find is a commit message template and (2) whether we got it from the commandline or configuration.

What I'm trying to figure out is whether other people were relying on the accidental "optional template" behavior or if there is some case where it is more useful. If so, it should be brought back.

Fabrício noticed that when the "[commit] template" configuration is misconfigured to point to a nonexistent file, ever since v1.7.4.2 (see 2140b140, 2011-02-25), "git commit" fails in a seemingly mysterious way:

	$ git commit
	fatal: could not read 'template': No such file or directory

In olden times, the message instead said

	Commit template file does not exist.

which makes it a little clearer that the --template option or corresponding configuration item is being misused. Let's move a little in that direction, by saying "could not read commit message template 'template'".

Note that the origin of the setting in the motivating ~/.gitignore is still unknown. Depending on the answer, it might be nice to start ignoring nonexistent commit templates again; if the problem is widespread, hopefully there will be more reports soon.

Noticed-by: Fabrício Nascimento <fabriciosn@gmail.com>
Analysis-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hi again,

Fabrício Nascimento wrote:

Thanks for these details. I looked through the packages in brew, but no obvious clues.

At least the problem could have been easier to debug. How about this patch, to start?

 builtin/commit.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Jonathan Nieder <jrnieder@gmail.com> writes:

It is a good start, but at this point do we know where the template_file came from? It does not seem rocket surgery to update git_commit_config() so that it stores the value taken from configuration file in a separate variable so that we can tell the difference in order to tweak the message.

Are there only these three kinds of "pathname" variables that can be configured?

 - Those to be always used (it is an error if missing);
 - Those to be always used (the calling code creat(2)s if missing); and
 - Those to be used only if already exist (otherwise ignored).

If so, a good way forward might be to update git_config_pathname() and tell it which kind of path we are talking about. For the first and the third kind, it would (after ~ expansion and other magic) stat the string and error out for the first kind and return NULL for the third kind. For the second kind, we do not need to do anything special. We may need to distinguish between files and dirs, so we might need 6 variations, not just 3, but that is a minor implementation detail.

This is one of the reasons that I tend to resist applying patches that add useless configuration variables "just because it seems useful".