Re: [RFC] Submodules in GIT

[Andy Parkins <andyparkins@gmail.com>]

On Tuesday 2006 November 28 09:36, Andreas Ericsson wrote:

> I'd actually prefer the second solution here and let git print a list of
> submodules with dirty state and ask for some sort of user-response
> before creating the actual commit. As non-interactive commits should
> always be clean, requiring user intervention on non-clean state should
> be a safe thing to do.

I'd agree.  However, is there a need to require user intervention?  Can we not 
make the following analogies to normal git operation:

file in working directory -> submodule working directory
file in index -> submodule repository

It's perfectly possible to make a commit with different contents in the index 
and the working directory - it shows up in the git-status output very nicely.  
Why not deal with submodules in the same way?

Now imagine the following repository:
  file1
  file2
  submodule1/file3
Make changes to file2 and file3, but don't update-index or commit.  git-status 
would show:

# Changed but not updated:
#   (use git-update-index to mark for commit)
#
#       modified:   file2
#       dirty:      submodule1
#
nothing to commit

Now "git-update-index file2" and git-status

# Updated but not checked in:
#   (will commit)
#
#       modified:   file2
#
# Changed but not updated:
#   (use git-update-index to mark for commit)
#
#       dirty:      submodule1/
#

Now do a commit in submodule1/ and git-status in the supermodule.

# Updated but not checked in:
#   (will commit)
#
#       modified:   file2
#       submodule:  submodule1/
#

Obviously the detail would be different, but you get the idea.  There is 
almost no difference between git-with-submodules and git-as-normal.

I suppose there would actually need to be an extra step were the submodule is 
added to the supermodule index.  So really there would be three states from 
git-status:

# Updated but not checked in:
#   (will commit)
#
#       modified:   file2
#
# Changed but not updated:
#   (use git-update-index to mark for commit)
#
#       modified:   file1
#       submodule:  submodule1/
#
# Dirty submodules:
#   (commit changes in the submodule to clean)
#
#       dirty:      submodule1/
#

Which means: since the last supermodule commit there has been
 * a change to file2, which is in the index and would be committed.
 * a change to file1, which is not in the index and won't be committed.
 * a commit to submodule1, which won't be committed
 * changes to the submodule working directory

This really reinforces Linus's interpretation that submodules are 
directories - they would presumably just get a new object type and be 
referenced in the tree object.  git-update-index would be blind to dirty 
submodules with no new commit, just as git-update-index on an unchanged file 
has no effect.

Has this question been answered yet?  How does the supermodule know which 
branch to track in the submodule?  Does it simply track HEAD or when the 
submodule is added to the supermodule is it told which branch to track?  I 
suppose it's got to be HEAD really hasn't it?


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE