Re: [PATCH v3] submodule: Allow tracking of the newest revision of a branch in a submodule

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 12, 2008, 01:17 UTC
Message-ID: <7v3agub396.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081212002101.292020@gmx.net>

"Fabian Franz" <FabianFranz@gmx.de> writes:

Show 18 quoted lines

>> Fabian Franz <git@fabian-franz.de> writes:
>> 
>> > However I have both cases: Stable development, where I need one special
>> > version and "wild" development, where I always want the newest published
>> > one.
>> 
>> I do not think supporting both styles of development is a bad idea.
>> 
>> However, use of 0{40} in the index and the resulting commit object in the
>> superproject means that this is a project-wide decision, not your personal
>> preference.  It is not implausible that you would want to do a wild
>> expeeriment in your own clone of a project that uses the "Stable
>> development" approach (hence the upstream never would want to have 0{40}
>> gitlink in its commits).
>
> Yes, but at the same time I might want to record it permanently as a project decision or play at my own with it ...
>
> So both styles should be supported.

While I think they both _could_ have uses, I do not necessarily agree with your "should be". First of all, I am not sure project wide 0{40} really makes sense.

By creating such a commit in your superproject, you are essentially claiming that you will work with _any_ future version of the subproject, which is rather absurd.

And using 0{40} in trees and in the index to mark it is not really necessary, and here is why.

You could tell the participants that you do not care the exact version by storing 0{40} in the trees and the index, but in order for you to tell them the tip of which branch of the subproject to use, you need to give that information (i.e. branch name) to them as well. Obviously there is not enough space to put that information in gitlink (we could make room and I have another implementation in mind but that will be a more involved change so for a moment let's not go there). The infomation will come somewhere out-of-band, not in trees nor in the index. And at that point, the presense of such an out-of-band information itself is a good enough cue that such a path in the superproject is for the "wilder" style of development with the submodule.

Such an out-of-band information is necessary to use submodules in distributed development already (iow, the commit object name in gitlink is not enough), and we already have a Porcelain convention for that. The canonical repository URL for each submodule path is distributed as part of the superproject in .gitmodules. I would imagine that the message from the project that says "we expect you to use 'wilder' development style with this submodule, and use the tip of frotz branch here", if it ever makes sense, can be recorded in .gitmodules as well.

When updating (or initializing) a submodule, we can check .gitmodules, and iff it is the "wilder" kind, we can set assume-unchanged in the index and run "cd there && git fetch $remote $branch && git checkout FETCH_HEAD^0" or whatever you did in your patch.

If the supermodule did not work well with the updated submodule in such a checkout, at least you have one commit that you can reset your submodule checkout to, if you do not wipe that information with 0{40} in the trees and in the index. The commit recorded in the gitlink can serve as the "project wide" suggested version to use, even in "wilder" development style that also suggests to use "tip of that branch".