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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 13, 2024, 17:18 UTC
Message-ID: <xmqqle105oko.fsf@gitster.g>
In-Reply-To: <8436c2bf-45cf-8009-14cd-c5ca708ece08@gmx.de>

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

Show 20 quoted lines

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