From: Junio C Hamano <hidden> Date: 2016-06-15 22:49:00
Jens Lehmann [off-list ref] writes:
The first patch in this series lets "git submodule summary" and "git
submodule status" ignore dirty submodules. I thought about teaching
them a "--ignore" option too, but didn't for two reasons: First, the
output of those commands is pretty much focused on commits. Second,
when using "git status" with the config option 'status.submodulesummary'
the submodule tree is scanned twice, once for "git status" and then
again for "git submodule summary". With this patch the second run is
gone, which is a big gain for users of 'status.submodulesummary' with
large submodules.
The second patch teaches "git status" the same "--ignore-submodules"
option that "git diff" recently learned. Ignoring all changes also
suppresses the output of "git submodule summary" when
'status.submodulesummary' is set.
After this series I am planning to add a config option 'ignore' to
.gitmodules, which can be set for each submodule to either "all",
"dirty", "untracked" or "none" (the default). "git diff" and "git
status" will use that config value for each submodule. Using
"--ignore-submodule" overrides this default (and the new parameter
"none" will be added there to able to override the config settings).
And to avoid having to do "git submdule sync" every time that option
changes, I would like to search for it in .git/config first. If it
is not found there, it will be taken from .gitmodules, if present.
So users can override the setting but if they don't, upstream can
change it easily (e.g. when a submodules .gitignore has been updated
so that "ignore=untracked" is no longer necessary anymore it can be
removed). Also switching branches will have an effect instantly if
the 'ignore' entry in .gitmodules is different between branches.
Opinions?
I think both patches make sense. It would be reassuring to hear from
people who are heavier submodule users than me, though...
Thanks.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:00
Junio C Hamano wrote:
It would be reassuring to hear from
people who are heavier submodule users than me, though...
Speaking of which, what ever came of the submodule dogfood experiment?
Given a patch to automatically resolve submodule-ejection/subtree-merge
conflicts, do you think a patch series to split off gitk and git-gui
as submodules could live in pu eventually?
Jonathan
From: Tay Ray Chuan <hidden> Date: 2016-06-15 22:49:00
Hi,
On Sat, Jun 26, 2010 at 3:01 AM, Jonathan Nieder [off-list ref] wrote:
Given a patch to automatically resolve submodule-ejection/subtree-merge
conflicts, do you think a patch series to split off gitk and git-gui
as submodules could live in pu eventually?
+1
They do sound like they'd fit into the submodule paradigm. Further,
having git use it would be a good showcase of the submodule feature -
or bug. :)
--
Cheers,
Ray Chuan
On Sat, Jun 26, 2010 at 3:01 AM, Jonathan Nieder [off-list ref] wrote:
quoted
Given a patch to automatically resolve submodule-ejection/subtree-merge
conflicts, do you think a patch series to split off gitk and git-gui
as submodules could live in pu eventually?
+1
They do sound like they'd fit into the submodule paradigm. Further,
having git use it would be a good showcase of the submodule feature -
or bug. :)
Yes, I think having them as a submodule makes lots of sense. But
submodules are not there yet. Unless I overlooked something, the
following issues must be resolved before having these two as a
submodule, otherwise people will complain (and rightfully so!):
1) Switching branches, merging, rebasing and resetting in the
superproject must result in a checkout of the matching submodule
work tree (right now you always have to issue a "git submodule
update" afterwards to get the submodules in sync).
2) On "git clone" the submodules must be cloned and checked out too
(currently you have to do a "git submodule update --init" after
cloning the superproject).
3) Switching between commits in the superproject where a directory
is replaced by a submodule or vice versa doesn't work right now.
Submodules should handle this situation, otherwise the commit
putting gitk and git gui into submodules would become a barrier.
I am working on these issues, but that will take some time. But when
they are solved, me too thinks that these two should become submodules.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:00
Jens Lehmann wrote:
1) Switching branches, merging, rebasing and resetting in the
superproject must result in a checkout of the matching submodule
work tree
Switching branches can change the HEAD commit of an already checked
out submodule, and switching branches can change the list of
submodules.
For the latter, maybe it would make sense to introduce ‘git checkout
--recursive’ which runs ‘submodule update --init --recursive’ after
checkout. IMHO, in git 2.0 this even ought to be made the default.
One could use --no-recursive to access the more flexible traditional
behavior.
2) On "git clone" the submodules must be cloned and checked out too
Does ‘git clone --recursive’ take care of it?
The Makefile would need to be tweaked to give a reasonable message
when the caller forgets to check out an important submodule.
3) Switching between commits in the superproject where a directory
is replaced by a submodule or vice versa doesn't work right now.
Submodules should handle this situation, otherwise the commit
putting gitk and git gui into submodules would become a barrier.
Yes, this is the fatal problem imho since it would affect basic
maintainance tasks. I consider maintainance of the branch (rather
than consumption) the most important piece to begin with; for a branch
not in next, usability problems can be resolved over time.
I am working on these issues, but that will take some time. But when
they are solved, me too thinks that these two should become submodules.
From: Marc Branchaud <hidden> Date: 2016-06-15 22:49:01
On 10-06-26 07:45 AM, Jens Lehmann wrote:
Yes, I think having them as a submodule makes lots of sense. But
submodules are not there yet. Unless I overlooked something, the
following issues must be resolved before having these two as a
submodule, otherwise people will complain (and rightfully so!):
I applaud all the current submodule work -- thanks a ton!
I would like to ask submodule developers to please keep in mind scenarios
where only a subset of the super-project's submodules are in use at one time.
In particular, please avoid forcing any blanket updates to all submodules.
I think the features being discussed would be much more useful if they only
applied to submodules that are already initialized and updated by the user,
and that any unintialized submodules should be left alone.
1) Switching branches, merging, rebasing and resetting in the
superproject must result in a checkout of the matching submodule
work tree (right now you always have to issue a "git submodule
update" afterwards to get the submodules in sync).
So, extending my request to this situation, I would say git should only
update submodules that are already initialzied and updated.
2) On "git clone" the submodules must be cloned and checked out too
(currently you have to do a "git submodule update --init" after
cloning the superproject).
Making clone do this automatically would be a show-stopper for us. The
current '--recursive' option is fine (though we never use it).
It would be interesting if the super-project could configure which submodules
to automatically clone.
(FYI, our build works along the lines of what Jonathan suggested: it
instructs folks on how to obtain missing submodules.)
M.
For the latter, maybe it would make sense to introduce ‘git checkout
--recursive’ which runs ‘submodule update --init --recursive’ after
checkout. IMHO, in git 2.0 this even ought to be made the default.
One could use --no-recursive to access the more flexible traditional
behavior.
Yup, I am working on that (I did post a WIP patch some time ago where
I added a '--ignore-submodules' option, but since then I changed my
mind on the name and now too think that '--[no-]recursive' is a much
better choice).
On 10-06-26 07:45 AM, Jens Lehmann wrote:
I applaud all the current submodule work -- thanks a ton!
Thanks for your feedback!
I would like to ask submodule developers to please keep in mind scenarios
where only a subset of the super-project's submodules are in use at one time.
In particular, please avoid forcing any blanket updates to all submodules.
I think the features being discussed would be much more useful if they only
applied to submodules that are already initialized and updated by the user,
and that any unintialized submodules should be left alone.
Yes. I think we agreed some time ago that until the user can configure the
wanted behavior only populated submodules should be touched, so I don't
mention that explicitly anymore.
quoted
1) Switching branches, merging, rebasing and resetting in the
superproject must result in a checkout of the matching submodule
work tree (right now you always have to issue a "git submodule
update" afterwards to get the submodules in sync).
So, extending my request to this situation, I would say git should only
update submodules that are already initialzied and updated.
Yes, see above.
quoted
2) On "git clone" the submodules must be cloned and checked out too
(currently you have to do a "git submodule update --init" after
cloning the superproject).
Making clone do this automatically would be a show-stopper for us. The
current '--recursive' option is fine (though we never use it).
It would be interesting if the super-project could configure which submodules
to automatically clone.
That's what I have in mind too. Maybe we could use the 'update' option of
.gitmodules to clone all those submodules where it is set. Then different
branches with different .gitmodules would behave differently.
From: Marc Branchaud <hidden> Date: 2016-06-15 22:49:01
On 10-06-28 03:00 PM, Jens Lehmann wrote:
quoted
quoted
2) On "git clone" the submodules must be cloned and checked out too
(currently you have to do a "git submodule update --init" after
cloning the superproject).
Making clone do this automatically would be a show-stopper for us. The
current '--recursive' option is fine (though we never use it).
It would be interesting if the super-project could configure which submodules
to automatically clone.
That's what I have in mind too. Maybe we could use the 'update' option of
.gitmodules to clone all those submodules where it is set. Then different
branches with different .gitmodules would behave differently.