Re: Reference a submodule branch instead of a commit

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 5, 2016, 16:13 UTC
Message-ID: <xmqqlgy2rcxq.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20161005141439.GD30930@book.hvoigt.net>

Heiko Voigt <hvoigt@hvoigt.net> writes:

Show 12 quoted lines

>> It IS a hack, but having this information in .git<something> would
>> mean that it can be forced to be in machine readable form, unlike a
>> mention in README.  I do not know if the .gitmodules/.gitignore
>> combination is a sensible thing to use, but it does smell like a
>> potentially useful hack.
>
> IIRC the tree entries are the reference for submodules in the code. We
> are iterating over the tree entries in many places so that change does
> not seem so easy to me.
>
> But you are right maybe we should stop arguing against this workflow and
> just let people use it until they find out whats wrong with it ;)

I didn't say that, though. I am fairly firm on _not_ changing what the superproject records in its tree for the submodule, i.e. it must record the exact commit, not "a branch name", for reproducibility.

I am OK if people ignored the unmatch between the recorded commit from a submodule and what they had in the submodule directory while they developed and tested the superproject commit. After all, it is not an error to make a commit while having a local uncommitted changes to tracked files, and it is equally valid to have a commit checked out in a submodule directory that is different from what goes in the superproject commit. But we do show "modified but not committed" in the status output. In that light, submodule.*.ignore may have been a mistake.