From: SZEDER Gábor <hidden> Date: 2016-06-15 23:07:20
The error message after a failing commit_lock_file() call sometimes
looks like this, causing confusion:
$ git remote add remote git@server.com/repo.git
error: could not commit config file .git/config
# Huh?!
# I didn't want to commit anything, especially not my config file!
While in the narrow context of the lockfile module using the verb
'commit' in the error message makes perfect sense, in the broader
context of git the word 'commit' already has a very specific meaning,
hence the confusion.
Reword these error messages to say "could not write" instead of "could
not commit".
While at it, include strerror in the error messages after writing the
config file or the credential store fails to provide some information
about the cause of the failure, and update the style of the error
message after writing the reflog fails to match surrounding error
messages (i.e. no '' around the pathname and no () around the error
description).
Signed-off-by: SZEDER Gábor <redacted>
---
The error message is of course bikeshedable.
Some callers of commit_lock_file() say something like "could not move
updated whatever file <path> into place: <strerror>" on error. While
it's truer to the meaning of the original error message and conveys
more exactly what went wrong (i.e. the actual writing had already
finished at that point, it's the move that failed), I think those
details are not necessary and the short and simple "could not write"
is better.
config.c | 6 ++++--
credential-store.c | 3 ++-
fast-import.c | 2 +-
refs.c | 2 +-
4 files changed, 8 insertions(+), 5 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 23:07:21
On Mon, Nov 30, 2015 at 12:40:53PM +0100, SZEDER Gábor wrote:
The error message after a failing commit_lock_file() call sometimes
looks like this, causing confusion:
$ git remote add remote git@server.com/repo.git
error: could not commit config file .git/config
# Huh?!
# I didn't want to commit anything, especially not my config file!
I like the intent of this patch; I've had the same "huh" moment myself.
The error message is of course bikeshedable.
You chose "write", which I think is OK. It's really a "rename", and
maybe that matters for some values of errno. I'd guess in practice
probably not (the likely reason is going to be something like EPERM).
And I can't think of a concise way to express rename (just saying
"rename" is confusing, too, without indicating that it's from the
tempfile to the final resting place).
So perhaps "write" is the best we can do.
-Peff
From: Eric Sunshine <hidden> Date: 2016-06-15 23:07:21
On Mon, Nov 30, 2015 at 6:40 AM, SZEDER Gábor [off-list ref] wrote:
quoted hunk
The error message after a failing commit_lock_file() call sometimes
looks like this, causing confusion:
$ git remote add remote git@server.com/repo.git
error: could not commit config file .git/config
# Huh?!
# I didn't want to commit anything, especially not my config file!
While in the narrow context of the lockfile module using the verb
'commit' in the error message makes perfect sense, in the broader
context of git the word 'commit' already has a very specific meaning,
hence the confusion.
Reword these error messages to say "could not write" instead of "could
not commit".
While at it, include strerror in the error messages after writing the
config file or the credential store fails to provide some information
about the cause of the failure, and update the style of the error
message after writing the reflog fails to match surrounding error
messages (i.e. no '' around the pathname and no () around the error
description).
Signed-off-by: SZEDER Gábor <redacted>
---
From: SZEDER Gábor <hidden> Date: 2016-06-15 23:07:22
The error message after a failing commit_lock_file() call sometimes
looks like this, causing confusion:
$ git remote add remote git@server.com/repo.git
error: could not commit config file .git/config
# Huh?!
# I didn't want to commit anything, especially not my config file!
While in the narrow context of the lockfile module using the verb
'commit' in the error message makes perfect sense, in the broader
context of git the word 'commit' already has a very specific meaning,
hence the confusion.
Reword these error messages to say "could not write" instead of "could
not commit".
While at it, include strerror in the error messages after writing the
config file fails, to provide some information about the cause of the
failure, and update the style of the error message after writing the
reflog fails, to match surrounding error messages (i.e. no '' around
the pathname and no () around the error description).
Signed-off-by: SZEDER Gábor <redacted>
---
Notes:
Changes since v1:
* Don't pass strerror() to die_errno().
config.c | 6 ++++--
credential-store.c | 2 +-
fast-import.c | 2 +-
refs.c | 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
From: SZEDER Gábor <hidden> Date: 2016-06-15 23:07:29
Signed-off-by: SZEDER Gábor <redacted>
---
v2 fixed this, but it fell on the floor, I suppose because of the
maintainer switch. Anyway, I should have noticed it while the patch
was still cooking, sorry.
credential-store.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 23:07:29
On Wed, Dec 16, 2015 at 12:22:55PM +0100, SZEDER Gábor wrote:
Signed-off-by: SZEDER Gábor <redacted>
---
v2 fixed this, but it fell on the floor, I suppose because of the
maintainer switch. Anyway, I should have noticed it while the patch
was still cooking, sorry.
Oops. I do remember seeing Eric point out the problem and I think I was
planning to fix it up before merging. But I didn't make a note in
whats-cooking, so Junio had no idea of my plan.