threads / patch / 45540

patch, 2 partsentry.c: submodule recursing: respect force flag correctly

Subject: [PATCH 1/2] entry.c: submodule recursing: respect force flag correctly

## tl;dr

8 messages between Mar 29, 2017 and Mar 29, 2017. Diffs are folded; open one to read it.

replies: 7people: 3as markdown or json

Stefan Beller· Mar 29, 2017, 18:37 UTC · lore

In case of a non-forced worktree update, the submodule movement is tested in a dry run first, such that it doesn't matter if the actual update is done via the force flag. However for correctness, we want to give the flag is specified by the user.

Signed-off-by: Stefan Beller <sbeller@google.com>
---
 entry.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to entry.c +1 −1
diff --git a/entry.c b/entry.c
index d2b512da90..645121f828 100644
--- a/entry.c
+++ b/entry.c
@@ -287,7 +287,7 @@ int checkout_entry(struct cache_entry *ce,
 			} else
 				return submodule_move_head(ce->name,
 					"HEAD", oid_to_hex(&ce->oid),
-					SUBMODULE_MOVE_HEAD_FORCE);
+					state->force ? SUBMODULE_MOVE_HEAD_FORCE : 0);
 		}
 
 		if (!changed)

-- 
2.12.0.rc1.52.g2de7d24de9.dirty
Stefan Beller· Mar 29, 2017, 18:37 UTC · re: Stefan Beller · lore

[PATCH 2/2] unpack-trees.c: align submodule error message to the other error messages

As the place holder in the error message is for multiple submodules, we don't want to encapsulate the string place holder in single quotes.

Signed-off-by: Stefan Beller <sbeller@google.com>
---
 unpack-trees.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to unpack-trees.c +1 −1
diff --git a/unpack-trees.c b/unpack-trees.c
index 8333da2cc9..9f386cc174 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -167,7 +167,7 @@ void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
 	msgs[ERROR_WOULD_LOSE_ORPHANED_REMOVED] =
 		_("The following working tree files would be removed by sparse checkout update:\n%s");
 	msgs[ERROR_WOULD_LOSE_SUBMODULE] =
-		_("Submodule '%s' cannot checkout new HEAD");
+		_("The following submodules cannot checkout a new HEAD:\n%s");
 
 	opts->show_all_errors = 1;
 	/* rejected paths may not have a static buffer */

-- 
2.12.0.rc1.52.g2de7d24de9.dirty
Jonathan Nieder· Mar 29, 2017, 18:48 UTC · re: Stefan Beller · lore

Re: [PATCH 2/2] unpack-trees.c: align submodule error message to the other error messages

Stefan Beller wrote:
> As the place holder in the error message is for multiple submodules,
> we don't want to encapsulate the string place holder in single quotes.
Makes sense.
Show 15 quoted lines
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>  unpack-trees.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 8333da2cc9..9f386cc174 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -167,7 +167,7 @@ void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
>  	msgs[ERROR_WOULD_LOSE_ORPHANED_REMOVED] =
>  		_("The following working tree files would be removed by sparse checkout update:\n%s");
>  	msgs[ERROR_WOULD_LOSE_SUBMODULE] =
> -		_("Submodule '%s' cannot checkout new HEAD");
> +		_("The following submodules cannot checkout a new HEAD:\n%s");

Nitpicking about wording: unless the user has adopted a strongly object-oriented point of view, it is Git that cannot checkout a new HEAD, not the submodule.

How about:
		_("Cannot update submodule:\n%s")

That's vague, but if I understand correctly the way this error gets used is equally vague --- i.e., a clearer message would involve finer-grained error codes.

Thanks, Jonathan

Junio C Hamano· Mar 29, 2017, 21:33 UTC · re: Jonathan Nieder · lore

Re: [PATCH 2/2] unpack-trees.c: align submodule error message to the other error messages

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 34 quoted lines
> Stefan Beller wrote:
>
>> As the place holder in the error message is for multiple submodules,
>> we don't want to encapsulate the string place holder in single quotes.
>
> Makes sense.
>
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> ---
>>  unpack-trees.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/unpack-trees.c b/unpack-trees.c
>> index 8333da2cc9..9f386cc174 100644
>> --- a/unpack-trees.c
>> +++ b/unpack-trees.c
>> @@ -167,7 +167,7 @@ void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
>>  	msgs[ERROR_WOULD_LOSE_ORPHANED_REMOVED] =
>>  		_("The following working tree files would be removed by sparse checkout update:\n%s");
>>  	msgs[ERROR_WOULD_LOSE_SUBMODULE] =
>> -		_("Submodule '%s' cannot checkout new HEAD");
>> +		_("The following submodules cannot checkout a new HEAD:\n%s");
>
> Nitpicking about wording: unless the user has adopted a strongly
> object-oriented point of view, it is Git that cannot checkout a new
> HEAD, not the submodule.
>
> How about:
>
> 		_("Cannot update submodule:\n%s")
>
> That's vague, but if I understand correctly the way this error gets
> used is equally vague --- i.e., a clearer message would involve
> finer-grained error codes.
Makes sense to me.
Thanks for helping.
Stefan Beller· Mar 29, 2017, 22:34 UTC · re: Junio C Hamano · lore

[PATCH] unpack-trees.c: align submodule error message to the other error messages

As the place holder in the error message is for multiple submodules, we don't want to encapsulate the string place holder in single quotes.

Signed-off-by: Stefan Beller <sbeller@google.com>
---
Show 7 quoted lines
> Nitpicking about wording: unless the user has adopted a strongly
> object-oriented point of view, it is Git that cannot checkout a new
> HEAD, not the submodule.
> 
> How about:
> 
>                 _("Cannot update submodule:\n%s")
> That's vague, but if I understand correctly the way this error gets
> used is equally vague --- i.e., a clearer message would involve
> finer-grained error codes.

Makes sense. Here is the patch. Let's roll this as its own instead of waiting for the discussion on the other patch to settle.

Thanks, Stefan

 unpack-trees.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to unpack-trees.c +1 −1
diff --git a/unpack-trees.c b/unpack-trees.c
index 8333da2cc9..0d82452f7f 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -167,7 +167,7 @@ void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
 	msgs[ERROR_WOULD_LOSE_ORPHANED_REMOVED] =
 		_("The following working tree files would be removed by sparse checkout update:\n%s");
 	msgs[ERROR_WOULD_LOSE_SUBMODULE] =
-		_("Submodule '%s' cannot checkout new HEAD");
+		_("Cannot update submodule:\n%s")
 
 	opts->show_all_errors = 1;
 	/* rejected paths may not have a static buffer */

-- 
2.12.1.442.ge9452a8fbc
Junio C Hamano· Mar 29, 2017, 22:47 UTC · re: Stefan Beller · lore

Re: [PATCH] unpack-trees.c: align submodule error message to the other error messages

Stefan Beller <sbeller@google.com> writes:
Show 38 quoted lines
> As the place holder in the error message is for multiple submodules,
> we don't want to encapsulate the string place holder in single quotes.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
>> Nitpicking about wording: unless the user has adopted a strongly
>> object-oriented point of view, it is Git that cannot checkout a new
>> HEAD, not the submodule.
>> 
>> How about:
>> 
>>                 _("Cannot update submodule:\n%s")
>
>> That's vague, but if I understand correctly the way this error gets
>> used is equally vague --- i.e., a clearer message would involve
>> finer-grained error codes.
>
> Makes sense. Here is the patch.
> Let's roll this as its own instead of waiting for the discussion on the other
> patch to settle.
>
> Thanks,
> Stefan
>
>  unpack-trees.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 8333da2cc9..0d82452f7f 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -167,7 +167,7 @@ void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
>  	msgs[ERROR_WOULD_LOSE_ORPHANED_REMOVED] =
>  		_("The following working tree files would be removed by sparse checkout update:\n%s");
>  	msgs[ERROR_WOULD_LOSE_SUBMODULE] =
> -		_("Submodule '%s' cannot checkout new HEAD");
> +		_("Cannot update submodule:\n%s")

Missing ';'. I'll fix locally, but the final integration result won't be pushed out until later tonight, as I need to redo jch and pu branches with a fixed version.

>  
>  	opts->show_all_errors = 1;
>  	/* rejected paths may not have a static buffer */
Jonathan Nieder· Mar 29, 2017, 18:45 UTC · re: Stefan Beller · lore

Re: [PATCH 1/2] entry.c: submodule recursing: respect force flag correctly

Stefan Beller wrote:
> In case of a non-forced worktree update, the submodule movement is tested
> in a dry run first, such that it doesn't matter if the actual update is
> done via the force flag. However for correctness, we want to give the
> flag is specified by the user.
"for correctness" means "to avoid races"?
Show 15 quoted lines
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>  entry.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/entry.c b/entry.c
> index d2b512da90..645121f828 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -287,7 +287,7 @@ int checkout_entry(struct cache_entry *ce,
>  			} else
>  				return submodule_move_head(ce->name,
>  					"HEAD", oid_to_hex(&ce->oid),
> -					SUBMODULE_MOVE_HEAD_FORCE);
> +					state->force ? SUBMODULE_MOVE_HEAD_FORCE : 0);
Looks like a good change.

This moves past the 80-column margin. I wish there were a tool like gofmt or clang-format that would take care of formatting for us.

This isn't the only place SUBMODULE_MOVE_HEAD_FORCE is used in the file. Do they need the same treatment?

Thanks, Jonathan

Junio C Hamano· Mar 29, 2017, 21:30 UTC · re: Jonathan Nieder · lore

Re: [PATCH 1/2] entry.c: submodule recursing: respect force flag correctly

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 8 quoted lines
> Stefan Beller wrote:
>
>> In case of a non-forced worktree update, the submodule movement is tested
>> in a dry run first, such that it doesn't matter if the actual update is
>> done via the force flag. However for correctness, we want to give the
>> flag is specified by the user.
>
> "for correctness" means "to avoid races"?
Sorry, but neither explanation makes much sense to me.

The codepath the patch touches says "if the submodule is not populated, then checkout the submodule by switching from NULL (nothing checked out) to the commit bound to the index of the superproject; otherwise, checkout the submodule by switching from HEAD (what is currently checked out) to the commit in the index".

Where does that "tested in a dry run first" come into play? Whatever code calls checkout_entry(), does it call it twice, first with a "--dry-run" option and then without one? How does this codepath respond differently to these two invocations, and how does this change affect the way these two invocations behave?

Show 27 quoted lines
>
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> ---
>>  entry.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/entry.c b/entry.c
>> index d2b512da90..645121f828 100644
>> --- a/entry.c
>> +++ b/entry.c
>> @@ -287,7 +287,7 @@ int checkout_entry(struct cache_entry *ce,
>>  			} else
>>  				return submodule_move_head(ce->name,
>>  					"HEAD", oid_to_hex(&ce->oid),
>> -					SUBMODULE_MOVE_HEAD_FORCE);
>> +					state->force ? SUBMODULE_MOVE_HEAD_FORCE : 0);
>
> Looks like a good change.
>
> This moves past the 80-column margin.  I wish there were a tool like
> gofmt or clang-format that would take care of formatting for us.
>
> This isn't the only place SUBMODULE_MOVE_HEAD_FORCE is used in the
> file.  Do they need the same treatment?
>
> Thanks,
> Jonathan

← back to recent threads