> On 24 June 2024 13:26:48 UTC, Sean Allred <allred.sean@xxxxxxxxx> wrote: >>This is an interesting idea, so far as I understand it. I certainly >>appreciate the desire to freeze your dependencies. I don't use >>submodules often, but I do want to point out an inherent assumption in >>your design: that tags don't move. >> >>Tags can move. It's usually impolite, but there can be reasonable >>use-cases for doing so. >> >>With this in mind, what can go wrong if you have a submodule with a >>configuration that doesn't necessarily match the tree? David <dark0dave@xxxxxxxxxxx> writes: > That's fine, my assumption is that if the tag moved the owner of the > repo intends this to happen. Like a hot fix or security change. > > What will happen is on update the submodule will be moved to the new > commit. Just like if a branch was updated. Its very similar code > between the two, as this is a super light touch change. I'm assuming that the superproject tree itself still gets the subproject commit OID, so the commit is still stable when tags in the subproject are moved (setting aside the possibility that the commit in the subproject may no longer be reachable... *shudder*). But doesn't it seem odd -- particularly for the concept of tags -- that the behavior of updating that tree could change depending on when you do it? For developers that add external dependencies as subprojects and choose to use this tagging feature, they could be in for a real surprise if they don't realize this quirk of the implementation -- and they could consider that behavior broken. If you're ok with that behavior, then does it make sense to generalize it to the concept of a ref instead of just a tag name? This may do a better job of communicating the idea that no ref is inherently immovable. (Not saying this is a good idea, but answering that question might further hone in on why tags are the 'right' choice here as opposed to any named commit.) -- Sean Allred
