From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:11
skimo@liacs.nl writes:
This patch series implements a mechanism for cloning submodules.
Let me start by asking a few stupid questions.
Each submodule is specified by a 'submodule.<submodule>.url'
configuration option, e.g.,
bash-3.00$ ./git-config --remote=http://www.liacs.nl/~sverdool/isa.git --get-regexp 'submodule\..*\.url'
submodule.cloog.url /home/sverdool/public_html/cloog.git
submodule.cloog.url http://www.liacs.nl/~sverdool/cloog.git
You are priming the process by having these configuration
variables in the superproject to be cloned (i.e. this is done by
the owner of the superproject).
git-checkout will use the first url that works.
E.g., a
git clone --submodules ssh://liacs/~/public_html/isa.git
followed by
git checkout origin/submodule
(which only works for me), will use the first url, while a
git clone --submodules http://www.liacs.nl/~sverdool/isa.git
followed by
git checkout origin/submodule
will use the second.
What's the design like to make clone and checkout work together?
When you run the first clone with -n ("do not checkout"), what
should happen (I am not asking what your code does, but what the
desired behaviour should be)? My take on that question is
"subproject cloning is done by checkout, not clone".
The cloning of submodules is now handled inside git-checkout.
which I guess means your answer is the same as mine, which
is fine.
I am very worried about this big red switch that says "all
subprojects to be cloned and checked out, or nothing". I think
this would not work well with projects that truly need
superproject support (i.e. very large ones, where most people
would not want to clone and check out every single subproject).
I currently do not fetch after the initial clone, since
I'm not sure what ref to use for the revision I need to
fetch for the supermodule.
I think fetching inside the subproject can be safely done with
the default (i.e. refs/heads/*:refs/remotes/origin/*) of 1.5.0
or later, as long as we tell the users of the feature that they
should make sure that the commit referenced by superproject tree
entries are available with such a fetch, which is a sane thing
to require anyway.
The more important issue I think is at what point in the
superproject operation does a recursive checkout in a subproject
should happen, and how we should do the checkout. Issues I can
think of offhand are (no way exhaustive):
- Do we checkout a branch? if so which one?
- Do we detach HEAD if the commit named by the superproject
tree is not at the tip of the current branch of subproject?
do we detach always even if the commit is at the tip?
- What would we do when the subproject working tree is not
clean?
- How can a user decide which subproject to descend into and
which subproject to ignore, and how does git remember the
earlier decision made by the user without asking the same
again, and how does a user express "now I want to also track
that subproject I've ignored so far" and "now I am not
interested in following that subproject anymore"?
So I tend to disagree with not having the indirection we
discussed on the other thread about .gitmodules, but I consider
it a minor detail of cloning, and it is not a major deal to me.
However, I agree with Alex that checkout semantics is a much
bigger deal, and would expect people (brighter than myself,
hopefully) to offer ideas.
You are priming the process by having these configuration
variables in the superproject to be cloned (i.e. this is done by
the owner of the superproject).
Is that a question?
The answer would be that if the user didn't put this information
in a config file, then git will try to get the information from
any remote it can get its hands on.
What's the design like to make clone and checkout work together?
When you run the first clone with -n ("do not checkout"), what
should happen (I am not asking what your code does, but what the
desired behaviour should be)? My take on that question is
"subproject cloning is done by checkout, not clone".
Then I guess you are not asking me.
I took the suggestion of doing the subproject cloning during checkout
from you.
I am very worried about this big red switch that says "all
subprojects to be cloned and checked out, or nothing". I think
this would not work well with projects that truly need
superproject support (i.e. very large ones, where most people
would not want to clone and check out every single subproject).
It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
Since the subcloning only happens at checkout, you could set these
before doing a checkout.
quoted
I currently do not fetch after the initial clone, since
I'm not sure what ref to use for the revision I need to
fetch for the supermodule.
I think fetching inside the subproject can be safely done with
the default (i.e. refs/heads/*:refs/remotes/origin/*) of 1.5.0
or later, as long as we tell the users of the feature that they
should make sure that the commit referenced by superproject tree
entries are available with such a fetch, which is a sane thing
to require anyway.
Seems like a pretty strict requirement, but it's easy to implement,
so I guess I can do that in the fourth version.
The more important issue I think is at what point in the
superproject operation does a recursive checkout in a subproject
should happen, and how we should do the checkout. Issues I can
think of offhand are (no way exhaustive):
- Do we checkout a branch? if so which one?
- Do we detach HEAD if the commit named by the superproject
tree is not at the tip of the current branch of subproject?
do we detach always even if the commit is at the tip?
I thought there was a consensus to detach the HEAD.
I don't have a strong opinion on this issue, but a detached
HEAD seems the most appropriate to me.
- What would we do when the subproject working tree is not
clean?
I was planning on adding a --dry-run to git-checkout.
The superproject would run this in each subproject before
doing the actual checkout of the superproject.
- How can a user decide which subproject to descend into and
which subproject to ignore, and how does git remember the
earlier decision made by the user without asking the same
again, and how does a user express "now I want to also track
that subproject I've ignored so far" and "now I am not
interested in following that subproject anymore"?
Just twiddle the "submodule.*.skip" option.
So I tend to disagree with not having the indirection we
discussed on the other thread about .gitmodules, but I consider
it a minor detail of cloning, and it is not a major deal to me.
Some form of indirection is definitely required (although
not for my use of submodules) and I'll probably add it in a future round.
skimo
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:11
Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
quoted
I am very worried about this big red switch that says "all
subprojects to be cloned and checked out, or nothing". I think
this would not work well with projects that truly need
superproject support (i.e. very large ones, where most people
would not want to clone and check out every single subproject).
It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
Since the subcloning only happens at checkout, you could set these
before doing a checkout.
And set them back after doing the checkout? And so for each and every
checkout operation? I suggest you try checkout something like KDE a
few times (well, assuming KDE is split in submodules. It isn't yet).
The point is - it is annoying. And if it is annoying, it wont be used
(as branches in CVS and merging in SVN).
quoted
The more important issue I think is at what point in the
superproject operation does a recursive checkout in a subproject
should happen, and how we should do the checkout. Issues I can
think of offhand are (no way exhaustive):
- Do we checkout a branch? if so which one?
- Do we detach HEAD if the commit named by the superproject
tree is not at the tip of the current branch of subproject?
do we detach always even if the commit is at the tip?
I thought there was a consensus to detach the HEAD.
I don't have a strong opinion on this issue, but a detached
HEAD seems the most appropriate to me.
Me too. I actually believe it is the only way to do it. How can you
checkout a subproject to something else (to what a branch may point)
and to what the tree of superproject has? On the other side (in
subproject) - why are you, the superproject, allowed to screw the
references of the subproject?! It is independent, isn't it?!
quoted
- What would we do when the subproject working tree is not
clean?
I was planning on adding a --dry-run to git-checkout.
The superproject would run this in each subproject before
doing the actual checkout of the superproject.
Why not do exactly what we do now? Pass "-m" down to it, if it was
given to the top-level git-checkout.
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:11
On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
quoted
quoted
I am very worried about this big red switch that says "all
subprojects to be cloned and checked out, or nothing". I think
this would not work well with projects that truly need
superproject support (i.e. very large ones, where most people
would not want to clone and check out every single subproject).
It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
Since the subcloning only happens at checkout, you could set these
before doing a checkout.
And set them back after doing the checkout?
What do you mean? Why would you set them back?
I guess I'm missing something.
Me too. I actually believe it is the only way to do it. How can you
checkout a subproject to something else (to what a branch may point)
and to what the tree of superproject has? On the other side (in
subproject) - why are you, the superproject, allowed to screw the
references of the subproject?! It is independent, isn't it?!
Well... the subproject as a whole is independent of the superproject,
but the checkout in the superproject is not entirely independent.
quoted
quoted
- What would we do when the subproject working tree is not
clean?
I was planning on adding a --dry-run to git-checkout.
The superproject would run this in each subproject before
doing the actual checkout of the superproject.
Why not do exactly what we do now? Pass "-m" down to it, if it was
given to the top-level git-checkout.
We want to be sure that all (selected) subprojects can be updated before
updating any, no?
skimo
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:11
Sven Verdoolaege, Sun, May 20, 2007 23:09:54 +0200:
On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
quoted
Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
quoted
quoted
I am very worried about this big red switch that says "all
subprojects to be cloned and checked out, or nothing". I think
this would not work well with projects that truly need
superproject support (i.e. very large ones, where most people
would not want to clone and check out every single subproject).
It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
Since the subcloning only happens at checkout, you could set these
before doing a checkout.
And set them back after doing the checkout?
What do you mean? Why would you set them back?
Why should I set them before doing a checkout?
I guess I'm missing something.
"checkout" is an operation which is done often. It never had to be
configured before.
quoted
Me too. I actually believe it is the only way to do it. How can you
checkout a subproject to something else (to what a branch may point)
and to what the tree of superproject has? On the other side (in
subproject) - why are you, the superproject, allowed to screw the
references of the subproject?! It is independent, isn't it?!
Well... the subproject as a whole is independent of the superproject,
but the checkout in the superproject is not entirely independent.
Junio was talking about branch in subproject, wasn't he?
quoted
quoted
quoted
- What would we do when the subproject working tree is not
clean?
I was planning on adding a --dry-run to git-checkout.
The superproject would run this in each subproject before
doing the actual checkout of the superproject.
Why not do exactly what we do now? Pass "-m" down to it, if it was
given to the top-level git-checkout.
We want to be sure that all (selected) subprojects can be updated before
updating any, no?
I guess passing "-m" to git-checkout _is_ an explicit permission from
the operator to perform a merge. Besides, it's visible: merge prints
something, user sees the "-m" in command history (or in script code).
Calling git-checkout twice even if we don't have to... it is kind of
ugly. Still need some dry-run this for normal case (checkout can be
modified to do this by default, I think).
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:11
hoi :)
On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
Me too. I actually believe it is the only way to do it. How can you
checkout a subproject to something else (to what a branch may point)
and to what the tree of superproject has? On the other side (in
subproject) - why are you, the superproject, allowed to screw the
references of the subproject?! It is independent, isn't it?!
right. except when you have some managed-by-superproject branch
which is known to be special ;-)
After all the submodule checkout is independent from its parent
repository, too -- so you don't screw anything *g*.
quoted
quoted
- What would we do when the subproject working tree is not
clean?
I was planning on adding a --dry-run to git-checkout.
The superproject would run this in each subproject before
doing the actual checkout of the superproject.
Why not do exactly what we do now? Pass "-m" down to it, if it was
given to the top-level git-checkout.
sounds good.
With submodules we have to consider one extra level of merging.
-m in the supermodule also means that an automatic merge of the
dirlink entry should be done. Which would execute git-merge in the
submodule. And merging in a dirty tree is a challenge of its own.
So if local changes conflict with the checkout we should just error out.
--
Martin Waitz
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:11
On Sun, May 20, 2007 at 11:24:32PM +0200, Alex Riesen wrote:
Sven Verdoolaege, Sun, May 20, 2007 23:09:54 +0200:
quoted
On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
quoted
Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
quoted
quoted
I am very worried about this big red switch that says "all
subprojects to be cloned and checked out, or nothing". I think
this would not work well with projects that truly need
superproject support (i.e. very large ones, where most people
would not want to clone and check out every single subproject).
It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
Since the subcloning only happens at checkout, you could set these
before doing a checkout.
And set them back after doing the checkout?
What do you mean? Why would you set them back?
Why should I set them before doing a checkout?
quoted
I guess I'm missing something.
"checkout" is an operation which is done often. It never had to be
configured before.
There is going to have to be *some* way of selecting which
subprojects you want to check out. A config option that you
have to set only once (or not at all if you are happy with
the default) seems to be the easiest way. You can have git-gui
set them for you if you want.
How would _you_ specify which subprojects to checkout ?
quoted
Well... the subproject as a whole is independent of the superproject,
but the checkout in the superproject is not entirely independent.
Junio was talking about branch in subproject, wasn't he?
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:11
hoi :)
On Sun, May 20, 2007 at 12:10:04PM -0700, Junio C Hamano wrote:
The more important issue I think is at what point in the
superproject operation does a recursive checkout in a subproject
should happen, and how we should do the checkout.
we should really move from our big clone thing to a simple
fetch+checkout wrapper.
And then integrate all the submodule logic into the actual checkout
step where it belongs.
We might also want to expand fetch to also fetch newly reachable
submodule commits (of a configurable subset of modules).
Issues I can think of offhand are (no way exhaustive):
- Do we checkout a branch? if so which one?
At least no off-the-shelf branch from the upstream repository of
the submodule.
To use some special branch allows to use normal git methods in
the submodule, too -- but I haven't been able to convince everybody
yet... So let's get it to a state where people can play with it
in real projects and let's see.
- Do we detach HEAD if the commit named by the superproject
tree is not at the tip of the current branch of subproject?
do we detach always even if the commit is at the tip?
We must not mess with random upstream branches of the submodule
just because they happen to reference the same tip.
That would be too confusing.
Either use one special branch or detach.
- What would we do when the subproject working tree is not
clean?
The same as with normal files:
error out if something is changed which conflicts with the requested
update.
When we have a special managed-by-supermodule branch and the submodule
has another branch currently checked out we can entirely ignore this
issue.
This really allows the user to deliberately keep one module in an
unclean state.
- How can a user decide which subproject to descend into and
which subproject to ignore, and how does git remember the
earlier decision made by the user without asking the same
again, and how does a user express "now I want to also track
that subproject I've ignored so far" and "now I am not
interested in following that subproject anymore"?
I'd simply use explicit checkout of a submodule and removal of
the submodule to be a fine way to express the user's wish.
Of course we also need some way to say: populate everything
below "src/target" or similar. But that is independent from
the rest.
--
Martin Waitz
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:11
Martin Waitz, Sun, May 20, 2007 23:40:26 +0200:
quoted
quoted
quoted
- What would we do when the subproject working tree is not
clean?
I was planning on adding a --dry-run to git-checkout.
The superproject would run this in each subproject before
doing the actual checkout of the superproject.
Why not do exactly what we do now? Pass "-m" down to it, if it was
given to the top-level git-checkout.
sounds good.
With submodules we have to consider one extra level of merging.
-m in the supermodule also means that an automatic merge of the
dirlink entry should be done. Which would execute git-merge in the
submodule. And merging in a dirty tree is a challenge of its own.
But it is not a merge. It is a checkout. Being another operation it
may even be disallow merges of subprojects. Just plainly tell user
that this checkout is not possible because there are changes in
subprojects and in the pointer to this subproject in the upper level
superproject, and that the user should think about committing in
subproject first.
So if local changes conflict with the checkout we should just error out.
On account of it being too complex. Always a good reason.
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:11
hoi :)
On Mon, May 21, 2007 at 12:24:10AM +0200, Alex Riesen wrote:
But it is not a merge. It is a checkout. Being another operation it
may even be disallow merges of subprojects. Just plainly tell user
that this checkout is not possible because there are changes in
subprojects and in the pointer to this subproject in the upper level
superproject, and that the user should think about committing in
subproject first.
If the user did commit and then you do a supermodule checkout -m you
will get a merge.
--
Martin Waitz
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:11
Martin Waitz, Mon, May 21, 2007 00:14:55 +0200:
quoted
- Do we detach HEAD if the commit named by the superproject
tree is not at the tip of the current branch of subproject?
do we detach always even if the commit is at the tip?
We must not mess with random upstream branches of the submodule
just because they happen to reference the same tip.
That would be too confusing.
Strange. The very same reason I heard when I tried to explain why
branches are good. The people found them confusing, just like you now.
They preach Perforce, too.
Either use one special branch or detach.
Why not just detach always?
quoted
- What would we do when the subproject working tree is not
clean?
The same as with normal files:
error out if something is changed which conflicts with the requested
update.
This is called tree-level merge. Done by -m option (it does more than
that, yes, but this one too). While at it we can do file-level merge
as well, why not?
When we have a special managed-by-supermodule branch and the submodule
has another branch currently checked out we can entirely ignore this
issue.
Detached head isn't special enough?
quoted
- How can a user decide which subproject to descend into and
which subproject to ignore, and how does git remember the
earlier decision made by the user without asking the same
again, and how does a user express "now I want to also track
that subproject I've ignored so far" and "now I am not
interested in following that subproject anymore"?
I'd simply use explicit checkout of a submodule and removal of
the submodule to be a fine way to express the user's wish.
The directory of the submodule will be back by the next
git-checkout-index (in the current implementation).
Not the .git's, so yes it is a fine way to express user's wish: he
just initialize the subprojects he wants (by whatever way).
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:11
Martin Waitz, Mon, May 21, 2007 00:55:22 +0200:
hoi :)
On Mon, May 21, 2007 at 12:24:10AM +0200, Alex Riesen wrote:
quoted
But it is not a merge. It is a checkout. Being another operation it
may even be disallow merges of subprojects. Just plainly tell user
that this checkout is not possible because there are changes in
subprojects and in the pointer to this subproject in the upper level
superproject, and that the user should think about committing in
subproject first.
If the user did commit and then you do a supermodule checkout -m you
will get a merge.
Only if the user continue to use the last branch (or the detached
head) the subproject was on. He don't have to, he can even return to
the commit which does not conflict, unless he have to complicate
things.
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:11
hoi :)
On Mon, May 21, 2007 at 01:02:48AM +0200, Alex Riesen wrote:
quoted
If the user did commit and then you do a supermodule checkout -m you
will get a merge.
Only if the user continue to use the last branch (or the detached
head) the subproject was on. He don't have to, he can even return to
the commit which does not conflict, unless he have to complicate
things.
just curious:
so you want to differenciate between a subproject HEAD which was
set by the superproject and other ones?
--
Martin Waitz
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:11
hoi :)
On Mon, May 21, 2007 at 12:58:10AM +0200, Alex Riesen wrote:
Martin Waitz, Mon, May 21, 2007 00:14:55 +0200:
quoted
quoted
- Do we detach HEAD if the commit named by the superproject
tree is not at the tip of the current branch of subproject?
do we detach always even if the commit is at the tip?
We must not mess with random upstream branches of the submodule
just because they happen to reference the same tip.
That would be too confusing.
Strange. The very same reason I heard when I tried to explain why
branches are good. The people found them confusing, just like you now.
They preach Perforce, too.
Sorry, you lost me.
I didn't say that branches are bad but that guessing branch names based on
their tip is bad.
quoted
Either use one special branch or detach.
Why not just detach always?
Which is just another name for "unnamed special branch" ;-)
When you give it a name you can actually use it even after you switched
to another one.
quoted
quoted
- What would we do when the subproject working tree is not
clean?
The same as with normal files:
error out if something is changed which conflicts with the requested
update.
This is called tree-level merge. Done by -m option (it does more than
that, yes, but this one too). While at it we can do file-level merge
as well, why not?
It's not that easy, for submodules we have different levels of dirty:
* submodule HEAD matches supermodule index, but submodule working
directory is dirty.
If the submodule update would touch any modified file then it should
fail.
If used with -m (or perhaps another option? after all this merge
is in a submodule) then it could do the file-level merge for dirty
files.
* submodule HEAD does not match supermodule index
normal checkout should error out if it would touch the submodule.
checkout -m has to merge submodule HEAD
And of course:
* index entry of submodule does not match the entry in supermodule HEAD.
Same as for files.
quoted
When we have a special managed-by-supermodule branch and the submodule
has another branch currently checked out we can entirely ignore this
issue.
From: Steven Grimm <hidden> Date: 2016-06-15 22:43:11
Sven Verdoolaege wrote:
It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
Since the subcloning only happens at checkout, you could set these
before doing a checkout.
Can I take this to mean that you intend the default behavior to be to
check out all subprojects, with individual ones suppressed via
configuration as needed?
Picture a corporate development environment with a common build system,
a couple common libraries, and a bunch of separate products. Product
developers will want to check out the build system (which would perhaps
be in the superproject), the libraries they need, and their own product.
They will rarely want to check out the other products, which could
account for the vast majority of the subprojects, and certainly won't
want to have to keep track of which new subprojects are appearing so
they can add those to the exclude list.
In other words, "I want the superproject and these four subprojects and
nothing else" should be a well-supported mode of operation. In many
cases developers will already know at clone time exactly what they want.
If I'm misunderstanding your intent, then never mind. :)
-Steve
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:11
On Mon, May 21, 2007 at 12:26:21AM +0200, Alex Riesen wrote:
Sven Verdoolaege, Sun, May 20, 2007 23:47:32 +0200:
quoted
How would _you_ specify which subprojects to checkout ?
Aren't the ones which already have .git in them are kind of specified?
Would you always recurse into these submodules, regardless of
any option?
Or would you want two options, one for handling the submodules
you have explicitly marked someway and one for getting all submodules?
skimo
From: Sven Verdoolaege <hidden> Date: 2016-06-15 22:43:11
On Sun, May 20, 2007 at 05:39:10PM -0700, Steven Grimm wrote:
Sven Verdoolaege wrote:
quoted
It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
Since the subcloning only happens at checkout, you could set these
before doing a checkout.
Can I take this to mean that you intend the default behavior to be to
check out all subprojects, with individual ones suppressed via
configuration as needed?
Or we could have a tri-state variable, with "yes" meaning handle
the submodule, "no" don't, and undefined meaning do whatever is
specified by the global submodules option.
Explicitly checking out a submodule could then set the variable to "yes".
skimo
From: Josef Weidendorfer <hidden> Date: 2016-06-15 22:43:11
On Monday 21 May 2007, Sven Verdoolaege wrote:
On Mon, May 21, 2007 at 12:26:21AM +0200, Alex Riesen wrote:
quoted
Sven Verdoolaege, Sun, May 20, 2007 23:47:32 +0200:
quoted
How would _you_ specify which subprojects to checkout ?
Aren't the ones which already have .git in them are kind of specified?
Would you always recurse into these submodules, regardless of
any option?
Or would you want two options, one for handling the submodules
you have explicitly marked someway and one for getting all submodules?
There should be a way for a superproject to specify useful sets of
subprojects for different developer roles, and these sets should be
versioned. It is also useful for a superproject to be able to say
"for this subproject to work, that other subprojects needs to be
checked out".
Both issues could be supported with a "dependson" setting in .gitmodules
(or better call this file ".gitprojects"?)
[subproject "german-translation"]
path = lang/german
dependson = docbuilds
[subproject "all-translations"]
dependson = german-translation france-translation japanese-translation
The syntax here only is RFC, including the fact that this example
puts the subproject identifier into the key, and the path as config.
If we do not go the .gitattributes way, IMHO this is more logical.
When cloning, one should be allowed to specify the subprojects one wants
to track, e.g.
git-clone --subproject=all-translations ...
Josef
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:11
hoi :)
On Mon, May 21, 2007 at 12:44:16PM +0200, Josef Weidendorfer wrote:
There should be a way for a superproject to specify useful sets of
subprojects for different developer roles, and these sets should be
versioned. It is also useful for a superproject to be able to say
"for this subproject to work, that other subprojects needs to be
checked out".
What subprojects to use is the responsibility of the build system and
we should not step on its shoes too much.
We should provide a simple way to populate a submodule, but all the
dependency handling should really be done in the build system /
package handling system on top of git, IMHO.
Perhaps we can simply provide "cd $subproject && git clone" to
automatically fetch all needed stuff from a default location and
checkout that subproject.
Then we can integrate that command in bitbake and whatnot or start
a new configuration management system on top of git which uses
dependencies from Makefiles etc. to automatically check out the
right set of subprojects. But that should really be on top of git.
--
Martin Waitz
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:12
Martin Waitz, Mon, May 21, 2007 01:12:01 +0200:
On Mon, May 21, 2007 at 01:02:48AM +0200, Alex Riesen wrote:
quoted
quoted
If the user did commit and then you do a supermodule checkout -m you
will get a merge.
Only if the user continue to use the last branch (or the detached
head) the subproject was on. He don't have to, he can even return to
the commit which does not conflict, unless he have to complicate
things.
just curious:
so you want to differenciate between a subproject HEAD which was
set by the superproject and other ones?
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:12
Steven Grimm, Mon, May 21, 2007 02:39:10 +0200:
Sven Verdoolaege wrote:
quoted
It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
Since the subcloning only happens at checkout, you could set these
before doing a checkout.
Can I take this to mean that you intend the default behavior to be to
check out all subprojects, with individual ones suppressed via
configuration as needed?
Neither fetch nor checkout none of them and leave the subproject
fetch+checkout as exercise to the user?
From: Martin Waitz <hidden> Date: 2016-06-15 22:43:12
hoi :)
On Tue, May 22, 2007 at 11:54:23PM +0200, Alex Riesen wrote:
Martin Waitz, Mon, May 21, 2007 01:12:01 +0200:
quoted
On Mon, May 21, 2007 at 01:02:48AM +0200, Alex Riesen wrote:
quoted
quoted
If the user did commit and then you do a supermodule checkout -m you
will get a merge.
Only if the user continue to use the last branch (or the detached
head) the subproject was on. He don't have to, he can even return to
the commit which does not conflict, unless he have to complicate
things.
just curious:
so you want to differenciate between a subproject HEAD which was
set by the superproject and other ones?
No. Why do you think that I want to do that?
I think I simply was too tired to read. ;-)
Your 'Only if the user continues to use...' suggested that he has a
different option, namely going to a branch which is not controlled
by the superproject.
And of course the user can go back to another commit, after checkout -m
created a merge... ;-)
--
Martin Waitz