threads / patch / 46941

patchsubmodule: spell out API of submodule_move_head

Subject: [PATCH] submodule: spell out API of submodule_move_head

## tl;dr

7 messages between Oct 9, 2017 and Oct 10, 2017. Diffs are folded; open one to read it.

replies: 6people: 3as markdown or json

Stefan Beller· Oct 9, 2017, 22:06 UTC · lore

This way users of this function do not need to read the implementation to know what it will do.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
 submodule.c |  5 -----
 submodule.h | 18 ++++++++++++++++++
 2 files changed, 18 insertions(+), 5 deletions(-)

Show changes to 2 files +18 −5

submodule.c, submodule.h

diff --git a/submodule.c b/submodule.c
index c1edc91a13..d12e4ea96c 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1507,11 +1507,6 @@ static void submodule_reset_index(const char *path)
 		die("could not reset submodule index");
 }
 
-/**
- * Moves a submodule at a given path from a given head to another new head.
- * For edge cases (a submodule coming into existence or removing a submodule)
- * pass NULL for old or new respectively.
- */
 int submodule_move_head(const char *path,
 			 const char *old,
 			 const char *new,
diff --git a/submodule.h b/submodule.h
index f0da0277a4..3c15977be9 100644
--- a/submodule.h
+++ b/submodule.h
@@ -111,6 +111,24 @@ extern void connect_work_tree_and_git_dir(const char *work_tree, const char *git
  */
 int submodule_to_gitdir(struct strbuf *buf, const char *submodule);
 
+/**
+ * Move the HEAD and content of the active submodule at 'path' from object id
+ * 'old' to 'new'.
+ *
+ * Updates the submodule at 'path' and files in its work tree to commit
+ * 'new'. The commit previously pointed to by the submodule is named by
+ * 'old'. This updates the submodule's HEAD, index, and work tree but
+ * does not touch its gitlink entry in the superproject.
+ *
+ * If the submodule did not previously exist, then 'old' should be NULL.
+ * Similarly, if the submodule is to be removed, 'new' should be NULL.
+ *
+ * If updating the submodule would cause local changes to be overwritten,
+ * then instead of updating the submodule, this function prints an error
+ * message and returns -1.
+ *
+ * If the submodule is not active, this does nothing and returns 0.
+ */
 #define SUBMODULE_MOVE_HEAD_DRY_RUN (1<<0)
 #define SUBMODULE_MOVE_HEAD_FORCE   (1<<1)
 extern int submodule_move_head(const char *path,

-- 
2.14.0.rc0.3.g6c2e499285

Jonathan Nieder· Oct 9, 2017, 22:22 UTC · re: Stefan Beller · lore

Re: [PATCH] submodule: spell out API of submodule_move_head

Stefan Beller wrote:

Show 9 quoted lines

> This way users of this function do not need to read the implementation to
> know what it will do.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>  submodule.c |  5 -----
>  submodule.h | 18 ++++++++++++++++++
>  2 files changed, 18 insertions(+), 5 deletions(-)

Looks good (well, you'd expect me to think that :)).  Thanks.

Junio C Hamano· Oct 10, 2017, 00:16 UTC · re: Stefan Beller · lore

Re: [PATCH] submodule: spell out API of submodule_move_head

Stefan Beller <sbeller@google.com> writes:

Show 15 quoted lines

> +/**
> + * Move the HEAD and content of the active submodule at 'path' from object id
> + * 'old' to 'new'.
> + *
> + * Updates the submodule at 'path' and files in its work tree to commit
> + * 'new'. The commit previously pointed to by the submodule is named by
> + * 'old'. This updates the submodule's HEAD, index, and work tree but
> + * does not touch its gitlink entry in the superproject.
> + *
> + * If the submodule did not previously exist, then 'old' should be NULL.
> + * Similarly, if the submodule is to be removed, 'new' should be NULL.
> + *
> + * If updating the submodule would cause local changes to be overwritten,
> + * then instead of updating the submodule, this function prints an error
> + * message and returns -1.

This is not a new issue (the removed comment did not mention this at all), but is it correct to say that updates to "index and work tree" was as if we did "git -C $path checkout new" (and of course, HEAD in the $path submodule must be at 'old')?

What should happen if 'old' does not match reality (i.e. old is NULL but HEAD does point at some commit, old and HEAD are different, etc.)? Should the call be aborted?

Show 5 quoted lines

> + * If the submodule is not active, this does nothing and returns 0.
> + */
>  #define SUBMODULE_MOVE_HEAD_DRY_RUN (1<<0)
>  #define SUBMODULE_MOVE_HEAD_FORCE   (1<<1)
>  extern int submodule_move_head(const char *path,

Jonathan Nieder· Oct 10, 2017, 00:27 UTC · re: Junio C Hamano · lore

Re: [PATCH] submodule: spell out API of submodule_move_head

Junio C Hamano wrote:

> Stefan Beller <sbeller@google.com> writes:

Show 20 quoted lines

>> +/**
>> + * Move the HEAD and content of the active submodule at 'path' from object id
>> + * 'old' to 'new'.
>> + *
>> + * Updates the submodule at 'path' and files in its work tree to commit
>> + * 'new'. The commit previously pointed to by the submodule is named by
>> + * 'old'. This updates the submodule's HEAD, index, and work tree but
>> + * does not touch its gitlink entry in the superproject.
>> + *
>> + * If the submodule did not previously exist, then 'old' should be NULL.
>> + * Similarly, if the submodule is to be removed, 'new' should be NULL.
>> + *
>> + * If updating the submodule would cause local changes to be overwritten,
>> + * then instead of updating the submodule, this function prints an error
>> + * message and returns -1.
>
> This is not a new issue (the removed comment did not mention this at
> all), but is it correct to say that updates to "index and work tree"
> was as if we did "git -C $path checkout new" (and of course, HEAD in
> the $path submodule must be at 'old')?

I don't understand the question. This comment doesn't say it's like "git checkout" --- are you saying it should?

The function is more like "git read-tree -m -u" (or --reset when SUBMODULE_MOVE_HEAD_FORCE is passed) than like "git checkout". Perhaps what you are hinting at is that read-tree --recurse-submodules is not necessarily the right primitive to implement "git checkout" with. But that's a separate issue from documenting the current behavior of the function.

> What should happen if 'old' does not match reality (i.e. old is NULL
> but HEAD does point at some commit, old and HEAD are different,
> etc.)?  Should the call be aborted?

No.

Thanks, Jonathan

Show 5 quoted lines

>> + * If the submodule is not active, this does nothing and returns 0.
>> + */
>>  #define SUBMODULE_MOVE_HEAD_DRY_RUN (1<<0)
>>  #define SUBMODULE_MOVE_HEAD_FORCE   (1<<1)
>>  extern int submodule_move_head(const char *path,

Junio C Hamano· Oct 10, 2017, 00:42 UTC · re: Jonathan Nieder · lore

Re: [PATCH] submodule: spell out API of submodule_move_head

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 7 quoted lines

>> This is not a new issue (the removed comment did not mention this at
>> all), but is it correct to say that updates to "index and work tree"
>> was as if we did "git -C $path checkout new" (and of course, HEAD in
>> the $path submodule must be at 'old')?
>
> I don't understand the question.  This comment doesn't say it's like
> "git checkout" --- are you saying it should?

No, I am pointing out that this comment does not say what it's like clearly enough. s/is it correct/am I correct/ would have been less prone to get misunderstood, I guess.

> The function is more like "git read-tree -m -u" (or --reset when
> SUBMODULE_MOVE_HEAD_FORCE is passed) than like "git checkout".

If it behaves like two-tree "read-tree -m -u", I'd say that the best explanation an average developer would understand is that the update done to "index and work tree" is like using 'git checkout' to switch to the branch whose tip is 'new'.

> Perhaps what you are hinting at is that read-tree --recurse-submodules
> is not necessarily the right primitive to implement "git checkout"
> with.  But that's a separate issue from documenting the current
> behavior of the function.

No, you are way too ahead in this discussion. I was merely saying that what the comment says was unclear and does not allow me to get that far due to lack of clear information ;-).

Show 5 quoted lines

>> What should happen if 'old' does not match reality (i.e. old is NULL
>> but HEAD does point at some commit, old and HEAD are different,
>> etc.)?  Should the call be aborted?
>
> No.

... and that is because?

When does it make sense to do a two-tree "read-tree -m -u" giving the 'old' that is very different from the real 'old' tree-ish that corresponds to where your index started at?

Jonathan Nieder· Oct 10, 2017, 00:55 UTC · re: Junio C Hamano · lore

Re: [PATCH] submodule: spell out API of submodule_move_head

Junio C Hamano wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Junio C Hamano wrote:

Show 11 quoted lines

>>> This is not a new issue (the removed comment did not mention this at
>>> all), but is it correct to say that updates to "index and work tree"
>>> was as if we did "git -C $path checkout new" (and of course, HEAD in
>>> the $path submodule must be at 'old')?
>>
>> I don't understand the question.  This comment doesn't say it's like
>> "git checkout" --- are you saying it should?
>
> No, I am pointing out that this comment does not say what it's like
> clearly enough.  s/is it correct/am I correct/ would have been less
> prone to get misunderstood, I guess.

No problem. I think a word or two about how it's like read-tree in the docstring could be an improvement.

> If it behaves like two-tree "read-tree -m -u", I'd say that the best
> explanation an average developer would understand is that the update
> done to "index and work tree" is like using 'git checkout' to switch
> to the branch whose tip is 'new'.

If it says it's like "git checkout", then I fear that can just lead to more confusion, since "git checkout" does a number of things (e.g. updating the HEAD symref) that this function does not do.

It could say that it's like "git reset --keep", I suppose.

[...]

Show 11 quoted lines

>>> What should happen if 'old' does not match reality (i.e. old is NULL
>>> but HEAD does point at some commit, old and HEAD are different,
>>> etc.)?  Should the call be aborted?
>>
>> No.
>
> ... and that is because?
>
> When does it make sense to do a two-tree "read-tree -m -u" giving
> the 'old' that is very different from the real 'old' tree-ish that
> corresponds to where your index started at?

Because that is not the purpose of the function.

The caller is responsible for setting 'old' appropriately. A word or two in that direction would not be a terrible thing.

All that said, I want this function to go away completely. :) Documenting how it currently behaves is just a good way to understand what is happening when doing so.

Thanks, Jonathan

Junio C Hamano· Oct 10, 2017, 01:06 UTC · re: Jonathan Nieder · lore

Re: [PATCH] submodule: spell out API of submodule_move_head

Jonathan Nieder <jrnieder@gmail.com> writes:

> All that said, I want this function to go away completely. :)

Oh, if you are planning to replace it with something else, then I wouldn't bother wasting my time trying to understand the updated comment, or making it more understandable by others.