Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 20, 2012, 05:39 UTC
Message-ID: <7v1ufou92h.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20121120011628.GD321@odin.tremily.us>

"W. Trevor King" <wking@tremily.us> writes:

Show 14 quoted lines

> On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:
>> "W. Trevor King" <wking@tremily.us> writes:
>> ...
>> > I think it's best to have users craft their own commit messages
>> > explaining why the branch was updated.  That said, an auto-generated
>> > hint (a la "git merge") would probably be a useful extra feature.
>> 
>> I am not quite sure I agree.  When the project says "Use the tip of
>> 'bar' branch for the submodule 'foo'" at the top-level, does an
>> individual user who is not working on the submodule 'foo' but merely
>> is using it have any clue as to why the submodule's 'foo' branch
>> 'foo' moved, or does he necessarily even care?
>
> If he doesn't care, why is he updating the submodule gitlink?

He may not be updating the gitlink with "git add foo" at the top-level superproject level. He is just using that submodule as part of the larger whole as he is working on either the top-level or some other submodule. And checkout of 'foo' is necessary in the working tree for him to work in the larger context of the project, and 'foo' is set to float at the tip of its 'bar' branch. And that checkout results in a commit that is different from the commit the gitlink suggests, perhaps because somebody worked in 'foo' submodule and advanced the tip of branch 'bar'.

So:

 - at the top-level superproject level, entry 'foo' in the HEAD tree
   points at an older commit;

 - 'foo/.git/HEAD' points at refs/heads/bar, which matches the
   working tree of 'foo' and the index foo/.git/index..

I am not sure what should happen to the entry 'foo' in the index of the top-level superproject after such a 'submodule floats at the tip' checkout, but I imagine that it must match the contents of foo/.git/HEAD's tree. Otherwise, "git diff" at the top-level would report local changes.

When committing his work at the top-level, he will see that 'foo' gitlink is updated in that commit; after all that combination is the context in which his work was done.

Or are you envisioning that such a check-out will and should show a local difference at the submodule 'foo' by leaving the index of the top-level superproject unchanged, and the user should refrain from using "git commit -a" to avoid having to describe the changes made on the 'bar' branch in the meantime in his top-level commit? That is certainly fine by me (I am no a heavy submodule user to begin with), but I am not sure if that is useful and helpful to the submodule users.