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 andyparkins@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html