I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.
Cheers,
Randall
The upcoming release (2.13) will have "git checkout --recurse-submodules",
which will checkout the submodules at the commit as recorded in the
superproject.
I plan to add an option "submodule.recurse" (name is subject to bikeshedding),
which would make the --recurse-submodules flag given by default for all commands
that support the flag. (Currently cooking we have reset
--recurse-submodules, already
existing there is push/pull).
I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.
I am trying to give the use case of having control over everything
(or rather mixed) more thought as well,
e.g. "checkout --recurse-submodules -b <name>" may want to
create the branches in a subset of submodules as well.
Thanks,
Stefan
The upcoming release (2.13) will have "git checkout --recurse-submodules", which will checkout the submodules
at the commit as recorded in the superproject.
I plan to add an option "submodule.recurse" (name is subject to bikeshedding), which would make the --recurse-submodules
flag given by default for all commands that support the flag. (Currently cooking we have reset --recurse-submodules, already
existing there is push/pull).
Brilliant! 😊
quoted
I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible >>semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very >>common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as >>currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.
I am trying to give the use case of having control over everything (or rather mixed) more thought as well, e.g. "checkout --recurse-submodules -b ><name>" may want to create the branches in a subset of submodules as well.
I have to admit that I just assumed it would have to work that way this would not be particularly useful. However, in thinking about it, we might want to limit the depth of how far -b <name> takes effect. If the super module brings in submodules entirely within control of the development group, having -b <name> apply down to leaf submodules makes sense (in some policies). However, if some submodules span out to, say, gnulib, that might not make particular sense. Some downward limit might be appropriate. Perhaps, in the submodule ref, you might want to qualify it as <commit>:<ref> (but the impact of that is probably and admittedly pretty horrid). I hesitate to suggest a numeric limit, as that assumes that submodules are organized in a balanced tree - which is axiomatically unreasonable. Maybe something in .git/config, like
[branch "topic*"]
submodules=a,b,c
But I suspect that would make things even more confusing.
Cheers,
Randall
The upcoming release (2.13) will have "git checkout
--recurse-submodules", which will checkout the submodules at the
commit as recorded in the superproject.
I plan to add an option "submodule.recurse" (name is subject to
bikeshedding), which would make the --recurse-submodules flag given by
default for all commands that support the flag. (Currently cooking we
have reset --recurse-submodules, already existing there is push/pull).
Well pull not so much...it'll do a recursive fetch but not a recursive
merge/rebase. That is something on the docket to get done in the next
couple months though.
quoted
I rather like the concept of supporting --recurse-submodules. The
complexity is that the branches in all submodules all have to have
compatible semantics when doing the checkout, which is by no means
guaranteed. In the scenario where you are including a submodule from
a third-party (very common - see gnulib), the branches likely won't
be there, so you have a high probability of having the command fail
or produce the same results as currently exists if you allow the
checkout even with problems (another option?). If you have control
of everything, then this makes sense.
I am trying to give the use case of having control over everything (or
rather mixed) more thought as well, e.g. "checkout
--recurse-submodules -b <name>" may want to create the branches in a
subset of submodules as well.
Thanks, Stefan
The upcoming release (2.13) will have "git checkout --recurse-submodules", which will checkout the submodules
at the commit as recorded in the superproject.
I plan to add an option "submodule.recurse" (name is subject to bikeshedding), which would make the --recurse-submodules
flag given by default for all commands that support the flag. (Currently cooking we have reset --recurse-submodules, already
existing there is push/pull).
Brilliant! 😊
quoted
quoted
I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible >>semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very >>common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as >>currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.
quoted
I am trying to give the use case of having control over everything (or rather mixed) more thought as well, e.g. "checkout --recurse-submodules -b ><name>" may want to create the branches in a subset of submodules as well.
I have to admit that I just assumed it would have to work that way this would not be particularly useful. However, in thinking about it, we might want to limit the depth of how far -b <name> takes effect. If the super module brings in submodules entirely within control of the development group, having -b <name> apply down to leaf submodules makes sense (in some policies). However, if some submodules span out to, say, gnulib, that might not make particular sense. Some downward limit might be appropriate. Perhaps, in the submodule ref, you might want to qualify it as <commit>:<ref> (but the impact of that is probably and admittedly pretty horrid). I hesitate to suggest a numeric limit, as that assumes that submodules are organized in a balanced tree - which is axiomatically unreasonable. Maybe something in .git/config, like
[branch "topic*"]
submodules=a,b,c
But I suspect that would make things even more confusing.
I thought about having yet-another-flag in the .gitmodules file, which
states if the submodule is extern or internal.
[submodule "gnulib"]
path=./gnulib
external = true # implies no branch for checkout -b --recurse-submodules
I think there are a couple more situations where such "external" submodules
are treated differently, so maybe we'd want to think carefully about
the actual name
as different workflows would want to have different features for an
internal/external
submodule.
Thanks,
Stefan
The upcoming release (2.13) will have "git checkout
--recurse-submodules", which will checkout the submodules at the commit as recorded in the superproject.
I plan to add an option "submodule.recurse" (name is subject to
bikeshedding), which would make the --recurse-submodules flag given
by default for all commands that support the flag. (Currently cooking we have reset --recurse-submodules, already existing there is push/pull).
Brilliant! 😊
quoted
quoted
I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible >>>semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very >>>common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as >>>currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.
quoted
I am trying to give the use case of having control over everything (or rather mixed) more thought as well, e.g. "checkout --recurse-submodules -b >><name>" may want to create the branches in a subset of submodules as well.
I have to admit that I just assumed it would have to work that way
this would not be particularly useful. However, in thinking about it,
we might want to limit the depth of how far -b <name> takes effect. If
the super module brings in submodules entirely within control of the
development group, having -b <name> apply down to leaf submodules
makes sense (in some policies). However, if some submodules span out
to, say, gnulib, that might not make particular sense. Some downward
limit might be appropriate. Perhaps, in the submodule ref, you might
want to qualify it as <commit>:<ref> (but the impact of that is
probably and admittedly pretty horrid). I hesitate to suggest a
numeric limit, as that assumes that submodules are organized in a
balanced tree - which is axiomatically unreasonable. Maybe something
in .git/config, like
[branch "topic*"]
submodules=a,b,c
But I suspect that would make things even more confusing.
I thought about having yet-another-flag in the .gitmodules file, which states if the submodule is extern or internal.
[submodule "gnulib"]
path=./gnulib
external = true # implies no branch for checkout -b --recurse-submodules
I think there are a couple more situations where such "external" submodules are treated differently, so maybe we'd want to think carefully about the >actual name as different workflows would want to have different features for an internal/external submodule.
I didn't want to open up that one, but yes. That makes sense. However, I don't like overloading what "external" means or might mean in the future. Would you consider a distinct Boolean for that, like inherit-branch=true?
Cheers,
Randall
The upcoming release (2.13) will have "git checkout
--recurse-submodules", which will checkout the submodules at the commit as recorded in the superproject.
I plan to add an option "submodule.recurse" (name is subject to
bikeshedding), which would make the --recurse-submodules flag given
by default for all commands that support the flag. (Currently cooking we have reset --recurse-submodules, already existing there is push/pull).
Brilliant! 😊
quoted
quoted
I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible >>>semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very >>>common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as >>>currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.
quoted
I am trying to give the use case of having control over everything (or rather mixed) more thought as well, e.g. "checkout --recurse-submodules -b >><name>" may want to create the branches in a subset of submodules as well.
I have to admit that I just assumed it would have to work that way
this would not be particularly useful. However, in thinking about it,
we might want to limit the depth of how far -b <name> takes effect. If
the super module brings in submodules entirely within control of the
development group, having -b <name> apply down to leaf submodules
makes sense (in some policies). However, if some submodules span out
to, say, gnulib, that might not make particular sense. Some downward
limit might be appropriate. Perhaps, in the submodule ref, you might
want to qualify it as <commit>:<ref> (but the impact of that is
probably and admittedly pretty horrid). I hesitate to suggest a
numeric limit, as that assumes that submodules are organized in a
balanced tree - which is axiomatically unreasonable. Maybe something
in .git/config, like
[branch "topic*"]
submodules=a,b,c
But I suspect that would make things even more confusing.
quoted
I thought about having yet-another-flag in the .gitmodules file, which states if the submodule is extern or internal.
quoted
[submodule "gnulib"]
path=./gnulib
external = true # implies no branch for checkout -b --recurse-submodules
quoted
I think there are a couple more situations where such "external" submodules are treated differently, so maybe we'd want to think carefully about the >actual name as different workflows would want to have different features for an internal/external submodule.
I didn't want to open up that one, but yes. That makes sense. However, I don't like overloading what "external" means or might mean in the future. Would you consider a distinct Boolean for that, like inherit-branch=true?
Something like that kind of already exists. The 'branch' field.
Internal repos would most likely use the '.' value to indicate that the
submodules should track the superproject's branch. While a value of say
'foo' would indicate that the submodule should always be on branch
'foo'; this could be used for external repositories.
From: Stefan Beller <hidden> Date: 2017-05-08 17:15:51
On Mon, May 8, 2017 at 10:08 AM, Brandon Williams [off-list ref] wrote:
quoted
quoted
[submodule "gnulib"]
path=./gnulib
external = true # implies no branch for checkout -b --recurse-submodules
quoted
I think there are a couple more situations where such "external" submodules are treated differently, so maybe we'd want to think carefully about the >actual name as different workflows would want to have different features for an internal/external submodule.
I didn't want to open up that one, but yes. That makes sense. However, I don't like overloading what "external" means or might mean in the future. Would you consider a distinct Boolean for that, like inherit-branch=true?
Something like that kind of already exists. The 'branch' field.
Internal repos would most likely use the '.' value to indicate that the
submodules should track the superproject's branch. While a value of say
'foo' would indicate that the submodule should always be on branch
'foo'; this could be used for external repositories.
so for external repos you'd keep the branch unset, such that
you strictly checkout the sha1 object into a detached HEAD.
Makes sense.
Thanks,
Stefan