git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH/RFC] rerere: error out on autoupdate failure
@ 2014-12-03  4:20 Jonathan Nieder
  2014-12-03 17:34 ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Nieder @ 2014-12-03  4:20 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

We have been silently tolerating errors by returning early with an
error that the caller ignores since rerere.autoupdate was introduced
in v1.6.0-rc0~120^2 (2008-06-22).  So on error (for example if the
index is already locked), rerere can return success silently without
updating the index or with only some items in the index updated.

Better to treat such failures as a fatal error so the operator can
figure out what is wrong and fix it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
I ran into this while auditing hold_locked_index callers.  Tests
still pass after this change.  Sensible?

 rerere.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/rerere.c b/rerere.c
index 1b0555f..195f663 100644
--- a/rerere.c
+++ b/rerere.c
@@ -477,27 +477,23 @@ out:
 
 static struct lock_file index_lock;
 
-static int update_paths(struct string_list *update)
+static void update_paths(struct string_list *update)
 {
 	int i;
-	int fd = hold_locked_index(&index_lock, 0);
-	int status = 0;
 
-	if (fd < 0)
-		return -1;
+	hold_locked_index(&index_lock, 1);
 
 	for (i = 0; i < update->nr; i++) {
 		struct string_list_item *item = &update->items[i];
 		if (add_file_to_cache(item->string, ADD_CACHE_IGNORE_ERRORS))
-			status = -1;
+			die("staging updated %s failed", item->string);
 	}
 
-	if (!status && active_cache_changed) {
+	if (active_cache_changed) {
 		if (write_locked_index(&the_index, &index_lock, COMMIT_LOCK))
 			die("Unable to write new index file");
-	} else if (fd >= 0)
+	} else
 		rollback_lock_file(&index_lock);
-	return status;
 }
 
 static int do_plain_rerere(struct string_list *rr, int fd)

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH/RFC] rerere: error out on autoupdate failure
  2014-12-03  4:20 [PATCH/RFC] rerere: error out on autoupdate failure Jonathan Nieder
@ 2014-12-03 17:34 ` Junio C Hamano
  2014-12-03 17:41   ` Junio C Hamano
  2014-12-03 18:52   ` [PATCH v2] " Jonathan Nieder
  0 siblings, 2 replies; 4+ messages in thread
From: Junio C Hamano @ 2014-12-03 17:34 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: git

Jonathan Nieder <jrnieder@gmail.com> writes:

> We have been silently tolerating errors by returning early with an
> error that the caller ignores since rerere.autoupdate was introduced
> in v1.6.0-rc0~120^2 (2008-06-22).  So on error (for example if the
> index is already locked), rerere can return success silently without
> updating the index or with only some items in the index updated.
>
> Better to treat such failures as a fatal error so the operator can
> figure out what is wrong and fix it.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> I ran into this while auditing hold_locked_index callers.  Tests
> still pass after this change.  Sensible?

I think what the change wants to do is sensible, but "tests still
pass" probably does not tell us very much.  You'd need a competing
writers (e.g. in real life a human user may open two terminals and
try to do things in the same repository from both terminals without
realizing that she is stomping on herself), which is expected to
break in unexpected ways ;-), which is not something the existing
tests would try to catch anyway.

>  rerere.c | 14 +++++---------
>  1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/rerere.c b/rerere.c
> index 1b0555f..195f663 100644
> --- a/rerere.c
> +++ b/rerere.c
> @@ -477,27 +477,23 @@ out:
>  
>  static struct lock_file index_lock;
>  
> -static int update_paths(struct string_list *update)
> +static void update_paths(struct string_list *update)
>  {
>  	int i;
> -	int fd = hold_locked_index(&index_lock, 0);
> -	int status = 0;
>  
> -	if (fd < 0)
> -		return -1;
> +	hold_locked_index(&index_lock, 1);
>  
>  	for (i = 0; i < update->nr; i++) {
>  		struct string_list_item *item = &update->items[i];
>  		if (add_file_to_cache(item->string, ADD_CACHE_IGNORE_ERRORS))
> -			status = -1;
> +			die("staging updated %s failed", item->string);

Instead of crafting a new message, why not just stop passing IGNORE_ERRORS
and have add_file_to_cache() report the failure?  That is:

	if (add_file_to_cache(item->string, 0))
        	return -1;

That way, the user will get more useful diagnosis because there are
different reasons why an "add" may fail and we give different error
messages to them.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH/RFC] rerere: error out on autoupdate failure
  2014-12-03 17:34 ` Junio C Hamano
@ 2014-12-03 17:41   ` Junio C Hamano
  2014-12-03 18:52   ` [PATCH v2] " Jonathan Nieder
  1 sibling, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2014-12-03 17:41 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> Instead of crafting a new message, why not just stop passing IGNORE_ERRORS
> and have add_file_to_cache() report the failure?  That is:
>
> 	if (add_file_to_cache(item->string, 0))
>         	return -1;

Err, that should be exit(128) to mimic die().

> That way, the user will get more useful diagnosis because there are
> different reasons why an "add" may fail and we give different error
> messages to them.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH v2] rerere: error out on autoupdate failure
  2014-12-03 17:34 ` Junio C Hamano
  2014-12-03 17:41   ` Junio C Hamano
@ 2014-12-03 18:52   ` Jonathan Nieder
  1 sibling, 0 replies; 4+ messages in thread
From: Jonathan Nieder @ 2014-12-03 18:52 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

We have been tolerating errors by returning early with an error that
the caller ignores since rerere.autoupdate was introduced in
v1.6.0-rc0~120^2 (2008-06-22).  So on error (for example if the index
is already locked), rerere can return success without updating the
index or with only some items in the index updated.

Better to treat such failures as a fatal error so the operator can
figure out what is wrong and fix it.

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

>>  	for (i = 0; i < update->nr; i++) {
>>  		struct string_list_item *item = &update->items[i];
>>  		if (add_file_to_cache(item->string, ADD_CACHE_IGNORE_ERRORS))
>> -			status = -1;
>> +			die("staging updated %s failed", item->string);
>
> Instead of crafting a new message, why not just stop passing IGNORE_ERRORS
> and have add_file_to_cache() report the failure?  That is:
> 
> 	if (add_file_to_cache(item->string, 0))
>         	return -1;

Good catch.  It turns out that add_file_to_index does not even pay
attention to the IGNORE_ERRORS flag.  On error it unconditionally
prints a message using 'return error()'.

builtin/add.c uses the IGNORE_ERRORS to flag to decide whether to
avoid die()-ing on error (and it still lets add_file_to_index print the
error to stderr in that case, so --ignore-errors is a bit of a misnomer).

	if (add_file_to_cache(dir->entries[i]->name, flags)) {
		if (!ignore_add_errors)
			die(_("adding files failed"));
		exit_status = 1;
	}

The message always says which file it failed to index, so I agree that
it makes sense to simply exit(128) here.

 rerere.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/rerere.c b/rerere.c
index 1b0555f..dbb2545 100644
--- a/rerere.c
+++ b/rerere.c
@@ -477,27 +477,26 @@ out:
 
 static struct lock_file index_lock;
 
-static int update_paths(struct string_list *update)
+static void update_paths(struct string_list *update)
 {
 	int i;
-	int fd = hold_locked_index(&index_lock, 0);
-	int status = 0;
 
-	if (fd < 0)
-		return -1;
+	hold_locked_index(&index_lock, 1);
 
 	for (i = 0; i < update->nr; i++) {
-		struct string_list_item *item = &update->items[i];
-		if (add_file_to_cache(item->string, ADD_CACHE_IGNORE_ERRORS))
-			status = -1;
+		if (add_file_to_cache(update->items[i].string, 0))
+			/*
+			 * add_file_to_cache() printed an error
+			 * with the pathname, so we don't have to.
+			 */
+			exit(128);
 	}
 
-	if (!status && active_cache_changed) {
+	if (active_cache_changed) {
 		if (write_locked_index(&the_index, &index_lock, COMMIT_LOCK))
 			die("Unable to write new index file");
-	} else if (fd >= 0)
+	} else
 		rollback_lock_file(&index_lock);
-	return status;
 }
 
 static int do_plain_rerere(struct string_list *rr, int fd)

^ permalink raw reply related	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-12-03 18:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-03  4:20 [PATCH/RFC] rerere: error out on autoupdate failure Jonathan Nieder
2014-12-03 17:34 ` Junio C Hamano
2014-12-03 17:41   ` Junio C Hamano
2014-12-03 18:52   ` [PATCH v2] " Jonathan Nieder

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).