Re: [RFC] Submodules in GIT

Daniel Barkalow wrote:
> On Sat, 25 Nov 2006, Linus Torvalds wrote:
> 
>> On Sun, 26 Nov 2006, Yann Dirson wrote:
>>> Also, I'd rather expect "git-commit -a" outside of any submodule to
>>> commit everything in the supermodule, triggering submodule commits as an
>>> intermediate step when needed - just like "git-commit -a" does not
>>> require to manually specify subdirectories to inclue in the commit.  I'd
>>> rather expect a special flag to exclude submodules from a commit.
>> So, how do you do commit messages? It generally doesn't make sense to 
>> share the same commit message for submodules - the sub-commits generally 
>> do different things.
> 
> The same way you do the first commit message. Ask independantly for each 
> commit message in sequence with enough context in the comment section that 
> you know what you're talking about.
> 
>> I'd actually suggest that "git commit -a" with non-clean submodules error 
>> out for that reason, with something like
>>
>> 	submodule 'src/xyzzy' is not up-to-date, please commit changes to 
>> 	that first.
>>
>> exactly because you really generally should consider the submodule commits 
>> to be a separate phase.
> 
> I think this is getting close to the classic usability blunder of having 
> the program tell you what you should have done instead of what you did, 
> and then making you do it yourself, rather than just doing it.
> 
> Just have it run "git commit -a" in each dirty submodule recursively as 
> part of preparing the index, since that's what the user wants to do 
> anyway, and nothing already done would be affected.
> 

Running "commit -a" is definitely the wrong thing to do, as it prevents 
one from using the index at all. Erroring out if the submodules are 
dirty, or just accepting the fact that they are and taking whatever 
commit HEAD points to is *always* preferrable.

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.

> "git commit -a -m <message>" should probably fail, of course.
> 

Why? There's no reason to rob this command of its power just because 
we're using submodules.

> 	-Daniel
> *This .sig left intentionally blank*
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html