Re: [PATCH v3] submodule: Allow tracking of the newest revision of a branch in a submodule
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:45
"Lars Hjemli" [off-list ref] writes:
On Thu, Dec 11, 2008 at 21:42, Junio C Hamano [off-list ref] wrote:quoted
I wonder if you can just set "assume unchanged" bit for the subproject gitlink in the index to achieve the same goal.Using assume-unchanged works, in the sense that the modification to the submodule is not detected in the containing repo. But running `git submodule update` will checkout the sha1 recorded in HEAD, and I suspect Fabian wants something like the hypothetical command `git submodule update -b [branch]` which could do `(cd sub && git fetch && git reset --hard origin/$branch)`.
Yeah, that would *also* make sense, but I think that is orthogonal issue.
You can update the state of the checkouts of subproject repositories in
any way you want. Doing so however makes "git commit -a" inconvenient to
use without assume-unchanged. The magic 0{40} which Fabian's patch
addresses the same issue in a different way.
Although I would probably detach the head at that point, rather than
resetting whatever branch happens to be checked out:
( cd sub && git fetch && git checkout origin/$branch^0 )
We also need to make sure that whatever we do we should not break
workflows that do not check out submodules that are uninteresting. So
doing the above unconditionally to all the submodules is out. In such a
sparsely populated superproject, "cd sub" would go to an empty directory,
and "git fetch" step would error out.
I did not read Fabian's patch too deeply, and do not remember what checks
it did before running "git pull". Perhaps it pulled unconditionally?