Thread (2 messages) flat view 2 messages, 2 authors, 2016-10-05

Re: Reference a submodule branch instead of a commit

From: Junio C Hamano <hidden>
Date: 2016-10-05 16:14:01

Heiko Voigt [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help