Re: [RFC] Submodules in GIT

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

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