Rostislav Krasny <rosti.bsd@xxxxxxxxx> writes: > On Wed, Jul 21, 2021 at 10:26 AM Atharva Raykar <raykar.ath@xxxxxxxxx> wrote: >> [...] >> We want to have idempotence, ie, for a particular revision that is >> registered by our parent project, we want 'update' to give the same >> outcome every time, and not be dependent on whatever the state of the >> branch is. This way we ensure that for a particular commit in the >> parent project, the submodules will be in the same state for every >> system in the world, after an 'update' is run. > > All this is ok, but there could be other uses of sub-modules. Why not > to make this behavior configurable? > > As a developer I may want to make new commits on those sub-modules and > always work with latest versions of their particular branches. In the > detached HEAD mode this is much harder to be done and also an error > prone operation. Commits that are done in the detached HEAD state may > easily be lost. [...] Have you tried running 'submodule update --merge' or 'submodule update --rebase'? Those modes will not detach your submodule's HEAD. The Pro Git book has a section that explains a workflow that sounds similar to what you describe: https://git-scm.com/book/en/v2/Git-Tools-Submodules Around halfway down the page, look for the heading "Working on a Submodule". Does that fit your use case? > [...] Google is full of questions about how this could be done, i.e. there > is an essential demand of such a new behavior. It would be nice if you can share a specific link that captures the demand you are talking about. When I Googled about this behaviour, I got a range of different kinds of results, without a clearly voiced demand. If you can show an example that best represents this demand, the Git developers here may be able to address it better.
