Phil Hord <hordp@xxxxxxxxx> writes:
> Now that you mention it, what happens if the submodule name changes in
> the history? What happens if the submodule URL (and possibly the entire
> submodule contents) changes in the history?
The original idea (dating back before "git submodule" was written, but
only when "gitlink" was added to the index and the tree objects) was to
identify the submodule by name and refer to the same logical entity with
the same name, so that no matter where in the superproject's working tree
hierarchy you change your mind to bind a particular submodule (say, "the
Linux kernel upstream source") at (i.e. "path"), or from which mirror of
the kernel repository you recommend your downstream to clone it from
(i.e. "url" in .gitmodules).
So "What happens if the submodule name changes" is a nonsense question.
But you remind me an ancient design discussion regarding the submodule URL
(you should dig the list archive if you are interested in reviving the
discussion of this issue), that hasn't been implemented.
It was envisioned that we sh/could record (in superproject's .git/config
somewhere) all the values of submodule.$name.url the user has ever seen
(via checkouts and branch switching), the value of submodule.$name.url
that was recorded in .gitmodules, along with what URL the user has
actually chosen to use given the set of these values.
Imagine that the original version of the superproject recommended A as the
URL for the submodule S, and then later versions of the superproject
recommend B as its URL because the project it borrows its submodule has
migrated to a new home.
A possible user experience under this scenario may go like this:
$ git clone superproject && cd superproject
$ git submodule init S
The user hasn't seen any submodule.S.url yet, as this is
immediately after cloning. .gitmodules records A and this
command would ask "Do you want to clone from A [Y/n]?" or use A
without asking.
It also records that when given A, the user chose A (or something
else, such as its known mirror A').
Time passes. The superproject changes the url for submodule S.
$ git pull
Now .gitmodules has B in submodule.S.url, which is different from
anything the user has seen (recorded in .git/config of
superproject). Any "git submodule" subcommand that would try to
update submodule S from its upstream _should_ offer the user a
chance to notice this, and update the actual URL in S/.git/config
to fetch from. It may ask "Do you want to update from B [Y/n]? "
and some other choices (e.g. keep using A' may be an option).
It also records that after seeing A and B, and to update the
version of superproject that records B as the URL for S, the user
chose to use what exact URL to update S (it may be A, B, or A', or
it may be something entirely different).
$ git checkout -b side master~400 ;# or whatever old version
After switching to an ancient version, .gitmodules has A. Perhaps
the module needs to be updated from A, or the module needs to be
updated from B (because A is defunct and no longer working, but B
records exactly the same history as A used to). But the record in
the superproject does not show what URL the user wants to use,
when A and B are the choices the user has seen, and A is recorded
in .gitmodules, so we ask again, and record the choice.
After this, we know that given the knowledge of presence of A and B,
what URL the user wants to use when .gitmodules records A (or B) as
the URL for the submodule, so switching to _any_ version in the
history will not have to ask the user what URL should be used to
interact with the upstream of submodule S.
Note that the above scenario can be loosened by assuming that B is always
a superset of A and newer recommendation is always preferred. Then the
mapping from the situation to the actual URL can be simplified to "Given
these URLs the user has seen, the user wants to use this URL", not "Given
these URLs the user has seen and this URL recorded in .gitmodules for the
particular version, the user wants to use this URL" as the above scenario
outlined.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html