Re: Adding nested repository with slash adds files instead of gitlink

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> >> Abusing a long standing bug does not make it a feature. I'm not
>> >> opposed to having a new option to keep that behavior, but it should
>> >> not be the default. If you use it that way, you're on your own.
>> >
>> > Was such an option ever worked on?
>>
>> No.
>>
>> I do not recall hearing anybody who have been active in the
>> development community saying anything good about such an option.
>> For the past 6 or so years, nobody who actively works on git thought
>> it was an interesting and/or useful thing to work on.
>>
>> I cannot quite say that they thought that it is actively a bad idea
>> to offer such an option, though.
>
> I have encountered the wish quite frequently to be able to make changes in
> a subdirectory and have them reflected as a commit that is both part of
> that subdirectory's revision history as well as part of the containing
> project's.

Let me make sure I understand the above.  You create a commit to
contain the change in the submodule and at the same time create a
new commit to bind the updated submodule commit to superproject
tree.  If that is what you are talking about, of course, that would
be a nice thing to have.  Sort of "commit --recursive".  It is still
debatable what to do with the log messages, though (you want to
leave in the submodule an explanation that is understandable in the
scope of the submodule, while you want to record in the superproject
a bigger picture reasoning).

But I did not get the impression that it is what the original poster
wants.  My reading of the original thread (this is a resurrection of
an antient thread dating back to 2018) was that you have a submodule
at path S, you muck with a file in S/file, and you want to commit in
the context of the superproject, having the superproject track S/file
in its history (not just S gitlink).

And that is quite different from what you said.