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

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

[Stefan Beller]

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

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

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

[Stefan Beller]

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

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

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

[Jonathan Nieder]

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.

Thanks,
Jonathan

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

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

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

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

[Stefan Beller]

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")
 
 	opts->show_all_errors = 1;
 	/* rejected paths may not have a static buffer */
-- 
2.12.1.442.ge9452a8fbc

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

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> 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 */

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

[Jonathan Nieder]

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

> 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

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

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> 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?



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