From: Junio C Hamano <hidden> Date: 2016-06-15 23:01:28
Chris Packham [off-list ref] writes:
On 04/06/14 09:05, Junio C Hamano wrote:
quoted
quoted
Also, going --recursive when the user did not want is a lot more
expensive mistake to fix than not being --recursive when the user
wanted to.
Having said all that, I do not mean to say that I am opposed to
introduce some mechanism to let the users express their preference
between recursive and non-recursive better, so that "git clone"
without an explicit --recursive (or --no-recursive) can work to
their taste. A configuration in $HOME/.gitconfig might be a place
to start, even though that has the downside of assuming that the
given user would want to use the same settings for all his projects,
which may not be the case in practice.
And here's a quick proof of concept. Not sure about the config variable name
and it could probably do with a negative test as well.
I would be more worried about the semantics than the name, though;
re-read the part you quoted with extra stress on "has the downside".
I think I heard the submodule folks (cc'ed) discuss an approach to
allow various submodules to be marked with "tags" with a new type of
entry in .gitmodules file in the superproject, and use these tags to
signal "by default, a new clone will recurse into this submodule".
E.g. if projects standardized on "defaultClone" to mark such
submodules, then $HOME/.gitconfig could say
[clone]
recursesubmodules = defaultClone
Or the projects may mark platform specific submodules with tags,
e.g. a .gitmodules in a typical superproject might say something
like this:
[submodule "posix"]
path = ports/posix
tags = linux obsd fbsd osx
[submodule "windows"]
path = ports/windows
tags = win32
[submodule "doc"]
path = documentation
tags = defaultClone
and then the user's $HOME/.gitconfig might say
[clone]
recursesubmodules = defaultClone win32
to tell a "git clone" of such a superproject to clone the top-level,
read its .gitmodules, and choose documentation/ and ports/windows
submodules but not ports/posix submodule to be further cloned into
the working tree of the superproject.
Of course, if this kind of project organization proves to be useful,
we should try to standardize the set of tags early before people
start coming up with random variations of the same thing, spelling
the same concept in different ways only to be different, and if that
happens, then we could even give a non-empty default value for the
clone.recursesubmodules when $HOME/.gitconfig is missing one.
Just a random thought.
Also, going --recursive when the user did not want is a lot more
expensive mistake to fix than not being --recursive when the user
wanted to.
Having said all that, I do not mean to say that I am opposed to
introduce some mechanism to let the users express their preference
between recursive and non-recursive better, so that "git clone"
without an explicit --recursive (or --no-recursive) can work to
their taste. A configuration in $HOME/.gitconfig might be a place
to start, even though that has the downside of assuming that the
given user would want to use the same settings for all his projects,
which may not be the case in practice.
And here's a quick proof of concept. Not sure about the config variable name
and it could probably do with a negative test as well.
I would be more worried about the semantics than the name, though;
re-read the part you quoted with extra stress on "has the downside".
I think I heard the submodule folks (cc'ed) discuss an approach to
allow various submodules to be marked with "tags" with a new type of
entry in .gitmodules file in the superproject, and use these tags to
signal "by default, a new clone will recurse into this submodule".
E.g. if projects standardized on "defaultClone" to mark such
submodules, then $HOME/.gitconfig could say
[clone]
recursesubmodules = defaultClone
Or the projects may mark platform specific submodules with tags,
e.g. a .gitmodules in a typical superproject might say something
like this:
[submodule "posix"]
path = ports/posix
tags = linux obsd fbsd osx
[submodule "windows"]
path = ports/windows
tags = win32
[submodule "doc"]
path = documentation
tags = defaultClone
and then the user's $HOME/.gitconfig might say
[clone]
recursesubmodules = defaultClone win32
to tell a "git clone" of such a superproject to clone the top-level,
read its .gitmodules, and choose documentation/ and ports/windows
submodules but not ports/posix submodule to be further cloned into
the working tree of the superproject.
Of course, if this kind of project organization proves to be useful,
we should try to standardize the set of tags early before people
start coming up with random variations of the same thing, spelling
the same concept in different ways only to be different, and if that
happens, then we could even give a non-empty default value for the
clone.recursesubmodules when $HOME/.gitconfig is missing one.
Yes, but maybe we can define how the user wants to set the global or
per-repo default (that is honored as long as upstream or local
config doesn't provide more specific settings, e.g. via tags) and
implement that for clone as a first step, even when we do not now
how e.g. the tags setting might look like in the end. I believe we
should have one or two switches telling Git "I want my submodules be
updated without having to use the 'git submodule' command". And
after that submodule specific overrides can kick in, e.g. when
"submodule.<name>.update" is set to "none" the submodule won't be
updated no matter how the default is.
We had two settings in mind, first "submodule.autoinit" (which would
automate the "git submodule --init" step and also control that a
new submodule is fetched into .git/modules; it'd be fetched there
soon as the fetch in the superproject sees a commit introducing it).
That would kick in on clone, fetch and pull, as the underlying fetch
honors it. And the "submodule.autoupdate" setting which will make
running "git submodule update" obsolete by updating all init'ed
submodules on each clone, checkout, merge, reset etc.. Together
they'd achieve for all relevant commands what Chris' proposed option
would only do for clone.
So what if clone would just do an "git submodule init" for now when
"submodule.autoinit" is set but "submodule.autoupdate" isn't (and as
soon as fetch learns to honor autoinit we could remove that one
again). And if both are set it'd do a "git submodule update --init
--recursive", just like it does when the --recurse-submodules option
is used. As soon as we also have recursive submodule update, we could
remove the latter from clone.
But maybe we are to close to the implementation side of things (where
fetch and checkout just like init and update are two separate things)
and a single "submodule.auto" setting would be what users really want?
Comments welcome.
On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote:
Chris Packham [off-list ref] writes:
quoted
On 04/06/14 09:05, Junio C Hamano wrote:
quoted
quoted
Also, going --recursive when the user did not want is a lot more
expensive mistake to fix than not being --recursive when the user
wanted to.
Having said all that, I do not mean to say that I am opposed to
introduce some mechanism to let the users express their preference
between recursive and non-recursive better, so that "git clone"
without an explicit --recursive (or --no-recursive) can work to
their taste. A configuration in $HOME/.gitconfig might be a place
to start, even though that has the downside of assuming that the
given user would want to use the same settings for all his projects,
which may not be the case in practice.
And here's a quick proof of concept. Not sure about the config variable name
and it could probably do with a negative test as well.
I would be more worried about the semantics than the name, though;
re-read the part you quoted with extra stress on "has the downside".
I think I heard the submodule folks (cc'ed) discuss an approach to
allow various submodules to be marked with "tags" with a new type of
entry in .gitmodules file in the superproject, and use these tags to
signal "by default, a new clone will recurse into this submodule".
E.g. if projects standardized on "defaultClone" to mark such
submodules, then $HOME/.gitconfig could say
[clone]
recursesubmodules = defaultClone
Or the projects may mark platform specific submodules with tags,
e.g. a .gitmodules in a typical superproject might say something
like this:
[submodule "posix"]
path = ports/posix
tags = linux obsd fbsd osx
[submodule "windows"]
path = ports/windows
tags = win32
[submodule "doc"]
path = documentation
tags = defaultClone
and then the user's $HOME/.gitconfig might say
[clone]
recursesubmodules = defaultClone win32
to tell a "git clone" of such a superproject to clone the top-level,
read its .gitmodules, and choose documentation/ and ports/windows
submodules but not ports/posix submodule to be further cloned into
the working tree of the superproject.
Of course, if this kind of project organization proves to be useful,
we should try to standardize the set of tags early before people
start coming up with random variations of the same thing, spelling
the same concept in different ways only to be different, and if that
happens, then we could even give a non-empty default value for the
clone.recursesubmodules when $HOME/.gitconfig is missing one.
Just a random thought.
I like this idea of specifying different "views" by giving tags. But
does it rule out a boolean clone.recursesubmodules? For the simple case
some people might not want to worry about specifying tags but just want
to configure: "Yes give me everything". So if we were to do this I would
like it if we could have both. Also because the option for clone is
--recurse-submodules and our typical schema is that a configuration
option is named similar so clone.recursesubmodules would fit here.
So either we do this "magically" and all valid boolean values are
forbidden as tags or we would need a different config option. Further
thinking about it: Maybe a general option that does not only apply to
clone would suit the "views" use-case more. E.g. "submodule.tags" or
similar.
Also please note: We have been talking about adding two configurations
for submodules:
submodule."name".autoclone (IIRC)
I am not sure whether that was the correct name, but this option should
tell recursive fetch / clone whether to automatically clone a submodule
when it appears on a fetch in the history.
submodule."name".autoinit
And this one is for recursive checkout and tells whether an appearing
submodule should automatically be initialized.
These options fullfill a similar use-case and are planned for the future
when recursive fetch/clone and checkout are in place (which is not that
far away). We might need to rethink these to incoporate the "views from
tags" idea nicely and since we do not want a configuration nightmare.
Cheers Heiko
From: Chris Packham <hidden> Date: 2016-06-15 23:01:29
On 05/06/14 07:42, Heiko Voigt wrote:
On Wed, Jun 04, 2014 at 10:24:06AM -0700, Junio C Hamano wrote:
quoted
Chris Packham [off-list ref] writes:
quoted
On 04/06/14 09:05, Junio C Hamano wrote:
quoted
quoted
Also, going --recursive when the user did not want is a lot more
expensive mistake to fix than not being --recursive when the user
wanted to.
Having said all that, I do not mean to say that I am opposed to
introduce some mechanism to let the users express their preference
between recursive and non-recursive better, so that "git clone"
without an explicit --recursive (or --no-recursive) can work to
their taste. A configuration in $HOME/.gitconfig might be a place
to start, even though that has the downside of assuming that the
given user would want to use the same settings for all his projects,
which may not be the case in practice.
And here's a quick proof of concept. Not sure about the config variable name
and it could probably do with a negative test as well.
I would be more worried about the semantics than the name, though;
re-read the part you quoted with extra stress on "has the downside".
I think I heard the submodule folks (cc'ed) discuss an approach to
allow various submodules to be marked with "tags" with a new type of
entry in .gitmodules file in the superproject, and use these tags to
signal "by default, a new clone will recurse into this submodule".
E.g. if projects standardized on "defaultClone" to mark such
submodules, then $HOME/.gitconfig could say
[clone]
recursesubmodules = defaultClone
Or the projects may mark platform specific submodules with tags,
e.g. a .gitmodules in a typical superproject might say something
like this:
[submodule "posix"]
path = ports/posix
tags = linux obsd fbsd osx
[submodule "windows"]
path = ports/windows
tags = win32
[submodule "doc"]
path = documentation
tags = defaultClone
and then the user's $HOME/.gitconfig might say
[clone]
recursesubmodules = defaultClone win32
to tell a "git clone" of such a superproject to clone the top-level,
read its .gitmodules, and choose documentation/ and ports/windows
submodules but not ports/posix submodule to be further cloned into
the working tree of the superproject.
Of course, if this kind of project organization proves to be useful,
we should try to standardize the set of tags early before people
start coming up with random variations of the same thing, spelling
the same concept in different ways only to be different, and if that
happens, then we could even give a non-empty default value for the
clone.recursesubmodules when $HOME/.gitconfig is missing one.
Just a random thought.
I like this idea of specifying different "views" by giving tags. But
does it rule out a boolean clone.recursesubmodules? For the simple case
some people might not want to worry about specifying tags but just want
to configure: "Yes give me everything". So if we were to do this I would
like it if we could have both. Also because the option for clone is
--recurse-submodules and our typical schema is that a configuration
option is named similar so clone.recursesubmodules would fit here.
Maybe using a glob pattern would work.
The user might say
[clone]
recursesubmodules = x86*
And .gitmodules might say
[submodule "foo"]
tags = x86_64
[submodule "bar"]
tags = x86
[submodule "frotz"]
tags = powerpc
For the "Yes give me everything" case the user could say
[clone]
recursesubmodules = *
So either we do this "magically" and all valid boolean values are
forbidden as tags or we would need a different config option. Further
thinking about it: Maybe a general option that does not only apply to
clone would suit the "views" use-case more. E.g. "submodule.tags" or
similar.
Also please note: We have been talking about adding two configurations
for submodules:
submodule."name".autoclone (IIRC)
I am not sure whether that was the correct name, but this option should
tell recursive fetch / clone whether to automatically clone a submodule
when it appears on a fetch in the history.
submodule."name".autoinit
And this one is for recursive checkout and tells whether an appearing
submodule should automatically be initialized.
These options fullfill a similar use-case and are planned for the future
when recursive fetch/clone and checkout are in place (which is not that
far away). We might need to rethink these to incoporate the "views from
tags" idea nicely and since we do not want a configuration nightmare.
Cheers Heiko
I'm a little confused at how autoclone and autoinit differ. Aren't they
the same? i.e. when this module appears grab it by default. I see
autoupdate as a little different meaning update it if it's been
initialised. Also does autoinit imply autoupdate?
At $dayjob we have a superproject which devs clone this has submodules
for the important and/or high touch repositories. We have other
repositories that are normally build from a tarball (or not built at
all) but we can build them from external repositories if needed. The
latter case is painfully manual. If autoinit/autoupdate existed we'd
probably setup out projects with.
[submodule "linux"]
autoinit = true
autoupdate = true
[submodule "userland"]
autoinit = true
autoupdate = true
[submodule "not-used-that-much"]
autoupdate = true
We probably wouldn't make use of tags because we're building complete
embedded systems and generally want everything, even if we are doing
most of our work on a particular target we need to do builds for other
targets for sanity checks.
On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
On 05/06/14 07:42, Heiko Voigt wrote:
quoted
I like this idea of specifying different "views" by giving tags. But
does it rule out a boolean clone.recursesubmodules? For the simple case
some people might not want to worry about specifying tags but just want
to configure: "Yes give me everything". So if we were to do this I would
like it if we could have both. Also because the option for clone is
--recurse-submodules and our typical schema is that a configuration
option is named similar so clone.recursesubmodules would fit here.
Maybe using a glob pattern would work.
The user might say
[clone]
recursesubmodules = x86*
And .gitmodules might say
[submodule "foo"]
tags = x86_64
[submodule "bar"]
tags = x86
[submodule "frotz"]
tags = powerpc
For the "Yes give me everything" case the user could say
[clone]
recursesubmodules = *
Thats interesting. Lets me/us think about that a little more.
quoted
So either we do this "magically" and all valid boolean values are
forbidden as tags or we would need a different config option. Further
thinking about it: Maybe a general option that does not only apply to
clone would suit the "views" use-case more. E.g. "submodule.tags" or
similar.
Also please note: We have been talking about adding two configurations
for submodules:
submodule."name".autoclone (IIRC)
I am not sure whether that was the correct name, but this option should
tell recursive fetch / clone whether to automatically clone a submodule
when it appears on a fetch in the history.
submodule."name".autoinit
And this one is for recursive checkout and tells whether an appearing
submodule should automatically be initialized.
These options fullfill a similar use-case and are planned for the future
when recursive fetch/clone and checkout are in place (which is not that
far away). We might need to rethink these to incoporate the "views from
tags" idea nicely and since we do not want a configuration nightmare.
I'm a little confused at how autoclone and autoinit differ. Aren't they
the same? i.e. when this module appears grab it by default. I see
autoupdate as a little different meaning update it if it's been
initialised. Also does autoinit imply autoupdate?
autoclone is about cloning the history of submodules. So e.g. when a
submodule first appears in the superprojects history whether it should
automatically be cloned to .git/modules.
autoinit is all about the checkout phase. When a commit with a new
submodule is checked out: Should that new submodule be automatically
initialised?
As far as autoupdate is concerned: Maybe autoinit can imply that it is
enabled, yes. But I guess we still need autoupdate for the case of big
submodules that cause to much performance trouble if updated by every
checkout.
So its actually three values: autoclone, autoinit, autoupdate. Damn,
these configurations become more complicated everytime. Maybe we should
try to clean them, up once we have everything, with Git 3.0 ;-) If
anyone has an idea how to get rid of some right now...
Radically different thinking: How about just one: submodule.auto =
true/false configuration and that means you opt in to doing everything
as automatic as possible. Since we are still implementing we could stick
a prominent warning in the documentation that the user should be
prepared for behavioral changes.
Once everybody is happy with that we could switch the default from false
to true.
At $dayjob we have a superproject which devs clone this has submodules
for the important and/or high touch repositories. We have other
repositories that are normally build from a tarball (or not built at
all) but we can build them from external repositories if needed. The
latter case is painfully manual. If autoinit/autoupdate existed we'd
probably setup out projects with.
[submodule "linux"]
autoinit = true
autoupdate = true
[submodule "userland"]
autoinit = true
autoupdate = true
[submodule "not-used-that-much"]
autoupdate = true
We probably wouldn't make use of tags because we're building complete
embedded systems and generally want everything, even if we are doing
most of our work on a particular target we need to do builds for other
targets for sanity checks.
Yep thats exactly what we already do at $dayjob but with
submodule.*.update=none. Since that conveniently also disables the
initialisation, developers only get the basic code and not everyone
needs to have the media and some big external libs.
I would reuse 'update' in the long run. But I guess for the transition
we will need the extra autoupdate one to keep annoyance levels low.
We currently also do not have real use cases for the tags/views
scenario, but as repositories grow I can see that it could be useful so
I would like it if we could keep the configuration open to that.
Cheers Heiko
On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
quoted
On 05/06/14 07:42, Heiko Voigt wrote:
quoted
So either we do this "magically" and all valid boolean values are
forbidden as tags or we would need a different config option. Further
thinking about it: Maybe a general option that does not only apply to
clone would suit the "views" use-case more. E.g. "submodule.tags" or
similar.
Also please note: We have been talking about adding two configurations
for submodules:
submodule."name".autoclone (IIRC)
I am not sure whether that was the correct name, but this option should
tell recursive fetch / clone whether to automatically clone a submodule
when it appears on a fetch in the history.
submodule."name".autoinit
And this one is for recursive checkout and tells whether an appearing
submodule should automatically be initialized.
These options fullfill a similar use-case and are planned for the future
when recursive fetch/clone and checkout are in place (which is not that
far away). We might need to rethink these to incoporate the "views from
tags" idea nicely and since we do not want a configuration nightmare.
I'm a little confused at how autoclone and autoinit differ. Aren't they
the same? i.e. when this module appears grab it by default. I see
autoupdate as a little different meaning update it if it's been
initialised. Also does autoinit imply autoupdate?
autoclone is about cloning the history of submodules. So e.g. when a
submodule first appears in the superprojects history whether it should
automatically be cloned to .git/modules.
autoinit is all about the checkout phase. When a commit with a new
submodule is checked out: Should that new submodule be automatically
initialised?
To me those two only make sense together, so I see them as a single
option. But then maybe some developers would like to clone everything
so they are plane-safe in case they intend to do "git submodule
update --init" later at 30.000 feet without internet access ... so
yes, technically we have three distinct steps: clone, init & update.
As far as autoupdate is concerned: Maybe autoinit can imply that it is
enabled, yes. But I guess we still need autoupdate for the case of big
submodules that cause to much performance trouble if updated by every
checkout.
So its actually three values: autoclone, autoinit, autoupdate. Damn,
these configurations become more complicated everytime. Maybe we should
try to clean them, up once we have everything, with Git 3.0 ;-) If
anyone has an idea how to get rid of some right now...
I suspect that once they are introduced we'll never be able to get
rid of them again ;-)
Radically different thinking: How about just one: submodule.auto =
true/false configuration and that means you opt in to doing everything
as automatic as possible. Since we are still implementing we could stick
a prominent warning in the documentation that the user should be
prepared for behavioral changes.
Once everybody is happy with that we could switch the default from false
to true.
I like that. (And if we really need /clone-but-no-init-or-update/ or
/clone-and-init-but-no-update/ settings later we could add two new
values additionally to true/false to make that work with a single
setting too). So I'm convinced that a single option is the way to go.
quoted
At $dayjob we have a superproject which devs clone this has submodules
for the important and/or high touch repositories. We have other
repositories that are normally build from a tarball (or not built at
all) but we can build them from external repositories if needed. The
latter case is painfully manual. If autoinit/autoupdate existed we'd
probably setup out projects with.
[submodule "linux"]
autoinit = true
autoupdate = true
[submodule "userland"]
autoinit = true
autoupdate = true
[submodule "not-used-that-much"]
autoupdate = true
We probably wouldn't make use of tags because we're building complete
embedded systems and generally want everything, even if we are doing
most of our work on a particular target we need to do builds for other
targets for sanity checks.
Yep thats exactly what we already do at $dayjob but with
submodule.*.update=none. Since that conveniently also disables the
initialisation, developers only get the basic code and not everyone
needs to have the media and some big external libs.
I would reuse 'update' in the long run. But I guess for the transition
we will need the extra autoupdate one to keep annoyance levels low.
I'm not sure reusing 'update' is going to work: 'update' currently
controls what "git submodule update" will do: nothing, checkout,
merge or rebase (and we shouldn't change that because of backwards
compatibility). We're talking about a new setting telling regular
git commands to do the submodule work tree update without having to
manually call "git submodule update". And I believe we'll always
need 'update' as it is for people who'll want to do a manual "git
submodule update", especially when we change the default of
'submodule.auto' to true in 3.0.
And by the way: wouldn't it make more sense to tell the user /what/
we do automatically? So maybe 'submodule.autoupdate' is a better
name for the new switch? The fact that it also does clone and init
under the hood looks more like a technical detail to the user, no?
And I'd like to avoid users uttering "auto-what?" when they hear
about this setting ;-) And it would make clear that 'update' is
what we do and 'autoupdate' makes it happen without having to call
"git submodule update".
From: W. Trevor King <hidden> Date: 2016-06-15 23:01:33
On Mon, Jun 09, 2014 at 03:17:07PM +0200, Jens Lehmann wrote:
And by the way: wouldn't it make more sense to tell the user /what/
we do automatically? So maybe 'submodule.autoupdate' is a better
name for the new switch?
Or autocheckout? No need to preserve submodule-specific jargon when
we have a perfectly acceptable word for this in the core interface ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy