Re: [RFC] Submodules in GIT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Andreas Ericsson                   andreas.ericsson@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]