[BUG] Git won't commit

[BUG] Git won't commit

[Fabricio Nascimento]

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.

Re: [BUG] Git won't commit

[Fabricio Nascimento]

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.

Re: [BUG] Git won't commit

[Michael Witten]

On Fri, Aug 12, 2011 at 17:13, Fabricio Nascimento <fabriciosn@gmail.com> wrote:
> 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.

What does the following output for you?

  git config --get commit.template

Re: [BUG] Git won't commit

[Michael Witten]

2011/8/12 Fabrício Nascimento <fabricio@tailorbirds.com.br>:
> Where git is the 1.7.6 that does not work, and git2 is the 1.7.4 that does
> work.
> [master 09-mapas] git config --get commit.template
> template
> [master 09-mapas] git2 config --get commit.template
> template

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.

Re: [BUG] Git won't commit

[Jonathan Nieder]

Hi,

Michael Witten wrote:

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

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.

[PATCH] commit: clarify "could not read 'template'" message

[Jonathan Nieder]

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:

> I have no idea what could have set the variable. Time Machine tells me the
> only changes on the .gitconfig file happened on August 12th, the day I've
> flagged the bug. I know I've made a brew upgrade on all my packages (that
> included git) the night before, and then the bug appeared the day after. I
> should have done only git stats, commit, pull and push.

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(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index cb738574..d029ec03 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -703,7 +703,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
 		hook_arg1 = "squash";
 	} else if (template_file) {
 		if (strbuf_read_file(&sb, template_file, 0) < 0)
-			die_errno(_("could not read '%s'"), template_file);
+			die_errno(_("could not read commit message template '%s'"),
+				  template_file);
 		hook_arg1 = "template";
 		clean_message_contents = 0;
 	}
-- 
1.7.6

Re: [PATCH] commit: clarify "could not read 'template'" message

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

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

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".

>  builtin/commit.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index cb738574..d029ec03 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -703,7 +703,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
>  		hook_arg1 = "squash";
>  	} else if (template_file) {
>  		if (strbuf_read_file(&sb, template_file, 0) < 0)
> -			die_errno(_("could not read '%s'"), template_file);
> +			die_errno(_("could not read commit message template '%s'"),
> +				  template_file);
>  		hook_arg1 = "template";
>  		clean_message_contents = 0;
>  	}