Thread (192 messages) flat view 192 messages, 22 authors, 2016-08-11

Re: [RFC] Submodules in GIT

From: Andreas Ericsson <hidden>
Date: 2016-08-11 19:56:53

Daniel Barkalow wrote:
On Sat, 25 Nov 2006, Linus Torvalds wrote:
quoted
On Sun, 26 Nov 2006, Yann Dirson wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help