Common tasks that could be performed with submodules

[GoogleCodeExporter]

We have a few super-project repos, with 5 to 10 submodules.  When the 
maintainer of the super-project has been notified that there are new 
updates to the submodules he should pick-up for use in his project, he 
needs to go through each submodule and manually fetch down the remote 
commits.  Then switch each submodule to a branch, then merge them all. 
It would be really useful if TGit supported the git submodule foreach 
command. 

For example: 

Fetching all remote commits and branches the local repo does not have: 
git submodule foreach 'git fetch'

Switching all submodules to a particular branch name: 
git submodule foreach 'git checkout BRANCHNAME'

Merging the latest commits from the submodules remotes: 
git submodule foreach 'git pull'

These could be added to the GUI.  In the context menu you have: 

Submodule Add 
Submodule Update

I think adding a fetch all option is a fairly easy one, as it doesnt 
depend on 'being on a branch', or whether the submodules contain the 
same branches: 

Submodule fetch all

This would pop-up a dialog similar to the fetch dialog, where the 
remote drop down would list all remotes that have the same name 
registered in each of the submodules remote config.  So where a 
submodule has a named remote that isnt common to the other submodules, 
it would not appear in the list. 

Then this would execute: 
git submodule foreach 'git fetch <chosen remote>' 

Submodule Switch/checkout all

Admittedly, a switch/checkout for all submodules is more difficult to 
define the rules for.  Perhaps similar to that fetch case above, a 
dialog is presented that lists all local branches that are common to 
all submodules.  When submodules are first created and updated, is it 
only the local master that is created?  If so, the user would 
obviously need to create branches that they need from the remote.  So 
it may be best to leave this feature to the simple case of selecting 
from already created local branches. 

Submodule Pull all 

This should only be available if all the submodules are currently on a 
branch, either from the result of 'Submodule Switch/checkout all' or 
if the user has manually checked out branches in each submodule. 
Then, similar to the fetch all case, this could pop-up a dialog where 
the remote drop down would list all remotes that have the same name 
registered in each of the submodules remote config.  So where a 
submodule has a named remote that isnt common to the other submodules, 
it would not appear in the list. 

Then this would execute: 
git submodule foreach 'git pull <chosen remote>' 

What version of the product are you using? On what operating system?
TGit 1.6.3-32bit
msysGit-1.7.3.1
WinXp SP3

Please provide any additional information below.
See 
http://groups.google.com/group/tortoisegit-dev/browse_thread/thread/420eb9044db0
fd74# for background discussion.

Original issue reported on code.google.com by kev.clark7@googlemail.com on 13 Feb 2011 at 11:17

[GoogleCodeExporter]

how about #246 can cover your requirement?

Original comment by lzn...@gmail.com on 14 Feb 2011 at 1:47

• Changed state: Discuss

[GoogleCodeExporter]

I certainly think #246 would be a useful feature, where you could build up a 
library of aliases for complex functions that you would typically do on the 
command line.  And realistically yes my requirements would be met by this.

But my suggestions above do give a bit of restriction with working with 
submodules (and for good reason), i.e. 'checkout all' would present a dialog 
where TGit would have determined what local branches are common to all 
submodules and only present those as available checkout branches from the 
dialog.

#246 would appear to suggest that custom commands are included as static 
aliases.  Whereas my suggestions would still require further user interaction 
to enter a name of a branch to checkout to, or enter a name of a remtoe to 
fetch/pull from.

If you think #246 could be implemented in such a way that is more than a simple 
alias to simple git commands, i.e. custom command that can be configured to 
include a number of user entered paramaters, then I would say #246 would do the 
job.

Eg:

Submodule fetch all:

git submodule foreach 'git fetch $1'

Where the user can configure what $1 is (i.e. the remote to fetch from).

However if a large team also makes use of these custom commands it could make 
deploying them a little difficult.  Perhaps custom commands could be stored in 
an external xml/config file that TGit and save/load from.

Original comment by kev.clark7@googlemail.com on 14 Feb 2011 at 12:58

[GoogleCodeExporter]

This is a duplicate of:
http://code.google.com/p/tortoisegit/issues/detail?id=246

Original comment by SMa...@gmail.com on 24 Dec 2011 at 12:46

[GoogleCodeExporter]

It is similar to #246.  Please read comment 
http://code.google.com/p/tortoisegit/issues/detail?id=711#c2.

Original comment by kev.clark7@googlemail.com on 24 Dec 2011 at 9:55

[GoogleCodeExporter]

Can
git submodule update
do the job?

Original comment by ch3co...@gmail.com on 4 Aug 2012 at 3:02

[GoogleCodeExporter]

Issue 1649 has been merged into this issue.

Original comment by ch3co...@gmail.com on 9 Mar 2013 at 12:12

[GoogleCodeExporter]

1. I cannot see why some of you think that this is duplicate of #246.
One thing is to enable integrating custom aliases, another is to build nice GUI 
for operating submodules.

2. I cannot understand why this issue is idle so much time.
We have just started using submodules in our repos. At this point of time we 
have not too much of them(4 project with 3 common submodules each). But we 
already have problems with maintaining. Some of them are the following:

2.1. There is no warning when we push superproject without pushing submodule. 
(Hopefully there is similar warning on commit).
2.2. We cannot make pull with recursive submodules update at one click (it 
would be useful in sync dialog).
2.3. There is no dialog where we can see tree of submodules with ability to:
2.3.1. Manage them (add, remove, move(change directory)). 
2.3.2. See whether each submodule is at some tag/branch.
2.3.3. Fetch specific submodule or all submodules at one click.
2.3.4. See whether we can pull some of submodules.

Functions 2.3.2 and 2.3.4 can be implemented using icons in something like 
treeview.
And imagine, you open a dialog, click "fetch all" and see what submodule can be 
pulled for a new version, where we have uncommmited changes and where we have 
unpushed commits.

All this stuff looks obvious for me after two week of using submodules. I 
hardly understand why such functionality is so weakly demanded.

Original comment by erto...@gmail.com on 19 Aug 2013 at 4:54